Redis в продакшене: масштабирование и эксплуатация

Запустить Redis легко. Удержать его живым под продакшен-нагрузкой, с отказоустойчивостью и без сюрпризов — отдельное искусство. Соберём всё в чек-лист.

Один Redis — единая точка отказа. Продакшен начинается там, где вы планируете, что будет, когда этот единственный сервер упадёт.

Финальный урок — про эксплуатацию Redis в бою: как обеспечить отказоустойчивость, масштабировать, мониторить и защищать. Это то, что отличает «работает у меня» от «работает под нагрузкой 24/7».

Репликация: копии данных

Redis умеет реплицировать: один мастер принимает записи, реплики получают копию данных. Реплики разгружают чтение и служат резервом. Но сама по себе репликация не переключает нагрузку при падении мастера — для этого нужен Sentinel.

   Репликация

   [Мастер] --поток изменений--> [Реплика 1]
       |                     --> [Реплика 2]
    записи                     (чтения, резерв)

Sentinel: автоматический failover

Redis Sentinel следит за мастером и репликами. Если мастер упал, Sentinel автоматически назначает одну из реплик новым мастером и сообщает клиентам. Это даёт высокую доступность без ручного вмешательства.

Cluster: горизонтальное масштабирование

Когда данные не помещаются в память одного сервера, нужен Redis Cluster: данные шардируются по 16384 «слотам», распределённым между узлами. Это даёт и масштаб по памяти, и масштаб по пропускной способности.

   Redis Cluster: данные шардированы по узлам

   ключи -> hash slot -> узел
   slot 0..5460     -> Узел A (+реплика)
   slot 5461..10922 -> Узел B (+реплика)
   slot 10923..16383-> Узел C (+реплика)

Мониторинг через INFO

Команда INFO — главный источник метрик. Ключевые показатели:

keyspace_hits / keyspace_misses — эффективность кэша (hit rate).
evicted_keys — сколько ключей вытеснено (рост = мало памяти).
used_memory — текущее потребление памяти.
connected_clients, instantaneous_ops_per_sec — нагрузка.

INFO stats        # хиты, промахи, вытеснения
INFO memory       # потребление памяти
INFO replication  # состояние мастер/реплик

Демонстрация: расчёт hit rate кэша на Python

# Считаем эффективность кэша по метрикам INFO
hits = 8500
misses = 1500

total = hits + misses
hit_rate = hits / total * 100

print(f"keyspace_hits:   {hits}")
print(f"keyspace_misses: {misses}")
print(f"Hit rate: {hit_rate:.1f}%")

if hit_rate >= 90:
    print("Отлично: кэш эффективен, БД хорошо разгружена.")
elif hit_rate >= 70:
    print("Приемлемо, но есть куда расти: проверьте TTL и набор кэшируемых данных.")
else:
    print("Низкий hit rate: кэш почти не помогает.")
    print("Причины: короткий TTL, частое вытеснение, кэшируется не то.")

# Сигнал тревоги по вытеснениям
evicted = 12000
print(f"\nevicted_keys: {evicted}")
if evicted > 0:
    print("Ключи вытесняются -> нужно больше памяти или короче TTL.")

Hit rate выше 90% — признак здорового кэша. Растущий evicted_keys — сигнал, что памяти не хватает или TTL слишком длинные.

Как работает под капотом

Репликация асинхронна: мастер шлёт репликам поток команд, поэтому реплика может чуть отставать. Sentinel — это отдельные процессы, которые голосованием (кворумом) решают, что мастер мёртв, и проводят failover. Cluster распределяет ключи по слотам с помощью CRC16 от имени ключа по модулю 16384; клиент знает карту слотов и идёт сразу на нужный узел. Все эти механизмы добавляют сложности, поэтому вводить их стоит только при реальной потребности.

Частые ошибки

Один Redis без репликации для критичного сервиса. Единая точка отказа.
Открытый Redis без пароля и без firewall. Классическая уязвимость; включайте requirepass и ограничивайте сеть.
Нет мониторинга. Без отслеживания памяти, hit rate и вытеснений проблемы всплывут только при падении.
Опасные команды на проде. KEYS *, FLUSHALL, FLUSHDB на боевом инстансе — отключайте или переименовывайте их.

Best practices (чек-лист продакшена)

Настройте персистентность (AOF everysec + RDB) под требования к данным.
Задайте maxmemory и политику вытеснения; следите за evicted_keys.
Обеспечьте отказоустойчивость: репликация + Sentinel (или managed-сервис).
Защитите доступ: пароль, ограничение сети, отключение опасных команд.
Мониторьте через INFO: hit rate, память, нагрузку, состояние репликации.
Всем кэш-ключам — TTL; обходите ключи через SCAN, а не KEYS.

Итог: Продакшен-Redis — это репликация для копий, Sentinel для автоматического failover, Cluster для шардирования больших данных, мониторинг через INFO и защита доступа. Один Redis без отказоустойчивости — единая точка отказа. Чек-лист выше превращает «работает» в «работает надёжно».