Как обеспечить надежность Redis кэша при потере данных

Что проверяют

Понимаете ли вы, что кеш по определению может исчезнуть, и что приложение обязано это переживать.

Как отвечать

Начните с главного принципа: кеш это ускорение, а не хранилище. Если потеря данных ломает работу, значит это уже не кеш, и относиться к нему нужно как к базе.

Что можно сделать на стороне Redis:

• сохранение на диск: снимки через заданные интервалы и журнал операций. Журнал с записью раз в секунду это разумный компромисс между потерями и скоростью;
• репликация: реплика с автоматическим переключением через Sentinel, либо кластер с разделением данных по узлам;
• политика вытеснения: при достижении лимита памяти данные вытесняются по заданному правилу. Для кеша обычно берут вытеснение редко используемых ключей, и это нормальная ситуация, а не сбой;
• раздельные экземпляры: кеш и очереди задач лучше держать отдельно, чтобы вытеснение не стирало то, что стирать нельзя.

Что делает приложение, и это важнее настроек:

• промах это обычный путь: данные пересчитываются из источника, а не приводят к ошибке;
• недоступность кеша не роняет сервис: короткий таймаут, обход кеша при ошибке, предохранитель, чтобы не ждать каждый раз;
• защита источника: при массовом промахе базу защищают блокировкой на пересчёт и разбросом сроков жизни ключей, иначе холодный старт положит базу;
• прогрев: после перезапуска популярные ключи наполняются фоново.

Где спотыкаются

Хранят в кеше единственную копию данных (сессии, корзину) без сохранения и репликации.

Возвращают ошибку пользователю при недоступности кеша.

Не разбрасывают сроки жизни, и после перезапуска сервиса база получает лавину одинаковых запросов.