Redis Cluster: кэширование и очереди сообщений для корпоративных приложений

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет в IT-инфраструктуре я поднял десятки Redis-инсталляций — от простого кэша на одном узле до шестиузлового кластера для биллинговой системы крупного дистрибьютора. И каждый раз одна и та же картина. Разработчики пихают в Redis всё подряд как временное решение, потом выясняется, что на нём завязана половина продакшена, а мастер стоит без реплики на одной виртуалке. В этой статье покажу, как правильно строить Redis Cluster так, чтобы не проснуться ночью от алерта.

Зачем бизнесу Redis и где он реально нужен

Redis — это in-memory key-value база. Читает за микросекунды, пишет почти так же быстро. У нас на практике он закрывает пять типовых сценариев:

• Кэш запросов к БД — разгрузка PostgreSQL/MSSQL, когда 80% чтений повторяются.
• Сессии веб-приложений — общий стор для кластера из N веб-серверов за балансировщиком.
• Очереди задач — Celery, Bull, RQ и другие пуш-очереди для фоновой обработки.
• Rate limiting — счётчики запросов API по IP или токену.
• Pub/Sub и Streams — уведомления в реальном времени между микросервисами.

Не надо тащить сюда транзакционные данные или аналитику — Redis не про это. Он про скорость и временные структуры.

Архитектура кластера: шарды и реплики

Минимальный production-кластер — 6 узлов: 3 мастера и 3 реплики. Каждому мастеру назначено ~5461 хэш-слотов из 16 384. Клиентский драйвер сам считает CRC16 от ключа, берёт остаток от 16384 и ходит в нужный шард. При падении мастера реплика с того же шарда становится новым мастером за 10-30 секунд.

Я всегда разношу мастер и его реплику по разным физическим серверам — в идеале и по разным стойкам. На одной железке держать обе ноги шарда бессмысленно: упадёт хост — потеряете весь шард до ручного вмешательства.

Железо у нас на продакшене — Dell PowerEdge с Xeon Platinum 8280, 256 ГБ RAM, NVMe под AOF-журналы. Сеть 40G Mellanox — именно сеть часто становится узким местом при реплицировании больших наборов.

Установка Redis 7 на Debian 12

Официальный репозиторий Redis Labs даёт свежие сборки. Ставим на все 6 узлов одинаково:

curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb bookworm main" \
  | sudo tee /etc/apt/sources.list.d/redis.list

sudo apt update && sudo apt install -y redis redis-tools
sudo systemctl enable --now redis-server

Дальше правим /etc/redis/redis.conf на каждом узле:

bind 0.0.0.0
port 6379
protected-mode yes
requirepass SuperStrongPassword123
masterauth SuperStrongPassword123

cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-require-full-coverage no

maxmemory 200gb
maxmemory-policy allkeys-lru

appendonly yes
appendfsync everysec
save 3600 1 300 100 60 10000

После рестарта systemctl restart redis-server на всех шести узлах собираем кластер одной командой:

redis-cli --cluster create \
  10.0.0.11:6379 10.0.0.12:6379 10.0.0.13:6379 \
  10.0.0.14:6379 10.0.0.15:6379 10.0.0.16:6379 \
  --cluster-replicas 1 -a SuperStrongPassword123

Мониторинг и алерты

Без мониторинга Redis — бомба замедленного действия. Память кончится, OOM-killer прибьёт процесс, пока вы спите. Я ставлю связку Prometheus + redis_exporter + Grafana:

Использование как очереди: Redis Streams

С версии 5.0 в Redis появился тип Stream — append-only лог с consumer groups, похожий на Kafka в миниатюре. Отлично подходит для фоновых задач между микросервисами.

# Производитель пишет в стрим
XADD orders * order_id 12345 amount 1500 customer ivanov

# Потребитель создаёт consumer group
XGROUP CREATE orders workers $ MKSTREAM

# Читаем с ack
XREADGROUP GROUP workers worker-1 COUNT 10 BLOCK 5000 STREAMS orders >
XACK orders workers 1705401234567-0

Реальный кейс: биллинг у дистрибьютора

В феврале 2026 к нам пришёл дистрибьютор бытовой техники. 380 рабочих мест в офисе, 1С:УТ + самописный личный кабинет для партнёров на PHP. Проблема — личный кабинет падал по таймаутам каждые 2-3 часа. Оказалось, на каждый заход пользователя делалось 40+ запросов в MSSQL, база не справлялась.

Развернули 6-нодовый Redis Cluster в дата-центре МТС, переписали слой запросов с кэшированием справочников на 300 секунд. Результат:

• Среднее время ответа личного кабинета: 2.3с → 180мс.
• Нагрузка на MSSQL по CPU: 78% → 22%.
• Очередь задач пересчёта балансов с cron-джоб переехала в Redis Streams.
• Стоимость работ — 220 000 ₽, срок 8 рабочих дней.

Типовые грабли и как на них не наступить

За годы работы я собрал коллекцию проблем, на которые регулярно жалуются:

• maxmemory не задан. Redis съест всю RAM и OOM-killer прибьёт его. Всегда ставим лимит ниже физической памяти.
• appendonly no с высокой нагрузкой. При падении теряете данные за период между RDB-снапшотами.
• Один datacenter. Для критичных сервисов держите ещё один шард в другой локации как read-only реплику.
• MULTI/EXEC через кластер без hash tags. Транзакция работает только в пределах одного слота — используйте {tag} в ключах.
• KEYS * в продакшене. Блокирует сервер на секунды. Только SCAN.

FAQ — частые вопросы по Redis Cluster

Чем Redis Cluster лучше одиночного сервера?

Горизонтальное масштабирование и автоматический failover: 16 384 слота распределяются по шардам, каждый шард имеет реплику. При падении мастера реплика становится мастером.

Сколько нужно узлов для минимального Redis Cluster?

Минимум 6: три мастера и три реплики. Меньшее число не даёт кворума при сбое.

Подходит ли Redis для очередей сообщений?

Redis Streams отлично работает как лёгкая очередь с consumer groups, ack и persistence. Для сложных маршрутизаций — RabbitMQ.

Нужна ли Sentinel при использовании Cluster?

Нет, Cluster сам обрабатывает failover. Sentinel нужен только в master-replica схеме.

Как делать бэкапы Redis?

RDB-снапшот + AOF-журнал. RDB каждый час, AOF с fsync everysec.