Какие проблемы бывают с Redis под высокой нагрузкой?

Модель выполнения. Сетевой ввод-вывод в Redis 6+ может идти в нескольких потоках, но сами команды исполняются последовательно в одном. Поэтому Redis быстрый (нет блокировок) — и поэтому одна долгая команда останавливает всех клиентов.

Опасные команды и шаблоны:

• KEYS * — полный перебор; вместо неё SCAN с курсором;
• HGETALL, SMEMBERS, LRANGE 0 -1, ZRANGE по большим структурам — O(N); читать порциями HSCAN, SSCAN;
• DEL большого ключа — освобождение памяти синхронно; UNLINK освобождает в фоне;
• долгие Lua-скрипты и MULTI с тяжёлыми командами;
• FLUSHALL без ASYNC.

Ищут через SLOWLOG, LATENCY DOCTOR, --bigkeys, --hotkeys (при LFU-политике), MEMORY USAGE.

Большие ключи — один хэш, список или множество на сотни мегабайт: медленные операции, неравномерная память в кластере (ключ не делится между узлами), долгая репликация и миграция слота. Решение — разбивать: cart:{user}:items вместо одного гигантского хэша на всех, бакеты по хешу поля.

Масштабирование:

• реплики — чтение с реплик (асинхронные — могут отставать), Sentinel для автоматического переключения;
• Redis Cluster — ключи распределены по 16384 слотам (CRC16 ключа), слоты — по узлам. Многоключевые команды и транзакции — только в пределах слота: хеш-теги {user:42}:cart и {user:42}:profile кладут ключи пользователя в один слот. Клиент знает карту слотов и получает MOVED при переезде;
• клиентский шардинг consistent hashing — старая альтернатива.

Память и вытеснение: maxmemory и политика (allkeys-lru, allkeys-lfu, volatile-ttl); без лимита Redis съест память и попадёт под OOM killer. Фрагментация — activedefrag.

Персистентность:

• RDB — снимок через fork: copy-on-write, при активной записи память может почти удвоиться, а fork большого процесса — задержка в десятки миллисекунд;
• AOF — журнал команд, appendfsync everysec — потеря до секунды;
• для чистого кэша персистентность часто выключают, для хранилища сессий и очередей — включают.

Ещё: пул соединений и pipelining для пачек команд; таймауты на клиенте; не использовать Redis как основную базу для данных, которые нельзя потерять, без понимания гарантий репликации (асинхронная — подтверждённая запись может исчезнуть при переключении).

redis-cli --bigkeys
  Biggest hash found 'sessions' has 2 418 309 fields      ← все сессии в одном ключе
redis-cli SLOWLOG GET 3
  1) HGETALL sessions — 1 820 ms                          ← все клиенты ждали почти 2 секунды
Решение: session:{id} отдельными ключами с TTL; HSCAN вместо HGETALL; UNLINK для удаления.