Redis как правильно использовать как кэш и не потерять данные

[artem_node41]

Используем Redis 7 как кэш сессий и горячих данных. Недавно упал один из серверов и мы потеряли все сессии — пользователей повыкидывало. Как настроить Redis так, чтобы при падении одного узла данные не терялись? И вообще стоит ли включать AOF если Redis используется только как кэш?

[vitaly_quant]

Для кэша сессий потеря данных при падении — это вообще-то ожидаемое поведение Redis в базовой конфигурации. Вопрос в том, что именно вы хотите: отказоустойчивость (данные не теряются) или высокую доступность (сервис работает даже при падении узла). Это разные задачи.

[appdev1427]

Для высокой доступности без потери данных нужен Redis Sentinel или Redis Cluster. Sentinel мониторит мастер, при падении промоутирует реплику в мастер — приложение переподключается и работает дальше. Replica lag при этом может привести к потере последних записей (зависит от настройки min-replicas-to-write), но большинство данных сохранится.

[vika_flux78]

AOF для кэша — спорно. AOF с fsync=always убьёт производительность (в разы), fsync=everysec даст потерю максимум 1 секунды данных при краше ОС, но замедлит запись. Для сессий я бы сделал Sentinel + RDB снапшоты каждые 5 минут — этого обычно достаточно, и производительность не страдает.

[kira_vue]

Развёрнуто по архитектуре: если это production и сессии критичны — минимальная схема это 1 master + 1 replica + 3 Sentinel-процесса (можно на тех же хостах). В redis.conf на мастере: replica-lazy-flush yes, на репликах: replica-read-only yes. Сентинели настраиваются через sentinel.conf с параметрами sentinel monitor mymaster <ip> <port> 2 (кворум 2 из 3). Приложение подключается к Sentinel, получает от него адрес актуального мастера. При падении мастера Sentinel через ~30 секунд (настраивается через sentinel down-after-milliseconds) промоутирует реплику. Если хотите Redis Cluster — это сложнее в настройке, но даёт горизонтальное масштабирование и автоматический шардинг. Для просто отказоустойчивости Sentinel проще.

[anna_data53]

Ещё момент: убедитесь что у сессий стоит TTL. Без TTL при падении и поднятии replica как новый master у вас постепенно накопится мусор. SET session:xxx данные EX 3600 — и не забивайте голову.

[dockerssh2428]

У нас похожая история была. В итоге вынесли сессии в отдельный Redis с AOF everysec + Sentinel, а основной кэш оставили без персистентности вообще. Логика: если кэш упал — прогреем заново, это больно но не катастрофа. Если сессии упали — пользователи злятся. Разные данные — разные требования к надёжности.