#python #redis #node-redis #nosql
#python #redis #узел-redis #nosql
Вопрос:
У меня есть некоторая путаница в redis. Я самообучаюсь redis.
Я узнал, что redis является однопоточным и работает по концепции цикла событий. Таким образом, операции чтения / записи сериализуются в redis, и условия гонки отсутствуют.
Мое замешательство — когда я наивно думаю об однопоточной архитектуре, я могу представить, что есть буфер, в котором собираются все запросы на чтение / запись, и поток планирует их один за другим. Но в реальном интернет-приложении, где должны обрабатываться тысячи или миллионы запросов, как redis обрабатывает эти запросы без значительных задержек? Если какая-либо операция записи занимает, скажем, несколько миллисекунд, блокирует ли она другую операцию чтения-записи в течение этого периода времени?
Реализует ли redis какую-либо концепцию блокировки, такую как реляционная БД? Если нет, то как redis обрабатывает тысячи операций чтения / записи без значительных задержек?
Любые внутренности / примеры были бы полезны для моего дальнейшего изучения.
Ответ №1:
Ваше понимание Redis internal совершенно правильное. Системы блокировки нет. Все операции являются атомарными и блокирующими.
При использовании Redis рекомендуется выполнять несколько коротких запросов вместо одного длинного. При написании запросов учитывайте временную сложность, упомянутую в документации Redis Commands, если вы работаете с большим количеством ключей или большой структурой данных. Избегайте команды KEYS, предпочитайте ей семейство команд SCAN. Будьте еще более осторожны при написании сценария Lua, который будет отправлен в Redis с помощью команды EVAL .
Каждый запрос, имеющий очень короткое время выполнения, в большинстве случаев на клиентах не повлияет тот факт, что команды Redis не будут отвечать ни на одну другую команду во время выполнения заданной.
В большинстве случаев ограничивающим фактором будет не сам Redis, а сеть.
Однако в некоторых случаях вы можете превысить пределы Redis (которые очень высоки). В этих случаях вы можете использовать несколько экземпляров Redis в режиме master-slave (репликация, контролируемая Redis Sentinel) и выполнять какое-то распределение нагрузки между экземплярами для запросов на чтение. Вы также можете использовать такой инструмент, как twemproxy, перед несколькими экземплярами Redis.