Redis кеширование в nodejs

Question

Итак, я смотрел на этот модуль, и я не могу понять, почему он использует обратные вызовы.

Я думал, что кеширование памяти должно быть быстрым, и это также цель, которую кто-то использует кеширование, потому что это быстро... как мгновение.

Добавление обратных вызовов подразумевает, что вам нужно что-то ждать. Но сколько вам нужно ждать на самом деле? Если результат возвращается к вам очень быстро, разве вы не замедляете процесс, оборачивая все в обратные вызовы + обещания сверху (потому что как пользователь этого модуля вы вынуждены обещать эти обратные вызовы)?

Answer 1

TLDR: чтение из памяти быстрое, чтение из сети медленнее и не должно блокировать процесс

Вы правы. Чтение из кеша памяти очень быстрое. Это так же быстро, как доступ к любой переменной (микро или нано секунд), поэтому нет веских оснований для реализации этого в качестве обратного вызова / обещания, поскольку это будет значительно медленнее. Но это верно только в том случае, если вы читаете из памяти процесса nodejs.

Проблема с использованием redis с узла заключается в том, что кэш памяти хранится на другом компьютере (сервере redis) или, по крайней мере, в другом процессе. Таким образом, даже если redis читает данные очень быстро, он все равно должен пройти через сеть, чтобы вернуться на сервер вашего узла, который не всегда гарантирует быструю работу (обычно, по крайней мере, несколько миллисекунд). Например, если вы используете сервер redis, который физически не расположен рядом с вашим сервером nodejs, или у вас слишком много сетевых запросов ... запрос может занять больше времени, чтобы достичь redis и вернуться на ваш сервер. А теперь представьте, что если это блокировка по умолчанию, это помешает вашему серверу делать что-либо еще, пока запрос не будет выполнен. Это приведет к очень низкой производительности, так как ваш сервер бездействует в ожидании отключения по сети. Вот почему любая операция ввода-вывода (диск, сеть, ..) в nodejs должна быть асинхронной по умолчанию.

Answer 2

По своей структуре javascript является асинхронным для большинства своих внешних вызовов (http, сторонние библиотеки, ...).

Как упомянуто здесь

Javascript - это однопоточный язык. Это означает, что у него один стек вызовов и одна куча памяти. Как и ожидалось, он выполняет код по порядку и должен завершить выполнение фрагмента кода, прежде чем перейти к следующему. Это синхронно, но иногда это может быть вредно. Например, если для выполнения функции требуется некоторое время или ей приходится что-то ждать, она все время замораживает.

Наличие синхронной функции блокирует поток и выполнение сценария. Чтобы избежать какой-либо блокировки (из-за работы в сети, доступа к файлу и т. Д.), Рекомендуется получать эту информацию асинхронно.

В большинстве случаев кэширование redis занимает несколько мс. Однако это предотвращает возможную задержку в сети и будет поддерживать работу вашего приложения с небольшим количеством ошибок подключения для ваших клиентов.

Answer 3

Алекс , вы отметили «Я думал, что кэширование памяти должно быть быстрым, и это также цель, по которой кто-то использует кэширование, потому что оно быстрое ... как мгновенное». И вы близки к тому, чтобы быть полностью верно.

Теперь, что на самом деле означает Redis?

Это означает REmote DIctionary Server.

~ FAQ - Redis

Да, словарь обычно работает в O(1) времени,Однако обратите внимание, что восприятие упомянутой производительности эффективно с точки зрения процедур, выполняющихся внутри процесса, содержащего словарь. Следовательно, доступ к памяти, принадлежащей процессу Redis из другого процесса, является каналом операций, который не является O(1).

Итак, поскольку Redis является REmote DIctionary Server Асинхронные API необходимы для доступа к его сервису.

Answer 4

Как уже было дано здесь ответом, ваш экземпляр redis может быть на вашем компьютере (и доступ к хранилищу RAM в Redis почти такой же быстрый, как и к доступной переменной javascript), но это также может быть другая машина / облако / кластер / вы. назови это. И в этом случае задержка в сети может быть проблематичной, поэтому синтаксис обещания / обратные вызовы.

Если вы на 100% уверены, что ваш экземпляр Redis всегда будет лежать на той же машине, что и ваш код, что имеет некоторую блокировкуасинхронные вызовы - это нормально, вы можете просто использовать синтаксис ES6 await, чтобы записать его как блокирующий синхронные события и избежать обратных вызовов или обещаний:)

Но я не уверен, что оно того стоит,с точки зрения привычки кодирования и масштабируемости. Но каждый проект индивидуален, и это может вас устроить.