Управляемый Redis хостинг с persistence

Redis поддерживает два режима persistence: RDB (Redis Database) делает периодические снапшоты всей памяти на диск каждые N минут, AOF (Append Only File) логирует каждую команду write в файл. RDB быстрее восстанавливается после сбоя и занимает меньше места, но при крэше теряете до N минут данных. AOF почти не теряет данные (fsync каждую секунду или каждую команду), но файл растёт быстро и требует периодической компактификации. Мы по умолчанию включаем оба: RDB снапшот каждые 5 минут плюс AOF с fsync every second. Это даёт максимум 1 секунду потерь при крэше. Для NVMe AOF с fsync always тоже возможен но снижает производительность в 5-10 раз.

Одиночный Redis - точка отказа. Падение сервера = простой приложения. Мы настраиваем Redis replication: один master принимает записи, один-два slave реплицируют асинхронно. Приложение читает с slaves для распределения нагрузки. При падении master нужен failover. Redis Sentinel - отдельный демон который мониторит health всех узлов и автоматически промоутит slave в master через консенсус трёх Sentinel-узлов. Failover занимает 30-60 секунд. Альтернатива - Redis Cluster с автоматическим шардингом по 16384 hash slot и встроенным failover. Cluster сложнее в настройке но не имеет single point of failure. Мы развернём любой вариант в зависимости от вашей нагрузки.

Redis применяется в десятках сценариев: Кэш HTTP-ответов между приложением и базой - снижение латентности в 10-100 раз, снижение нагрузки на Postgres/MySQL. Хранение сессий пользователей вместо файлов или БД - быстрый доступ из любой реплики приложения. Очереди задач через Redis Lists с BLPOP - basis для Celery, Bull, Sidekiq. Pub/Sub messaging для real-time уведомлений и WebSocket каналов. Rate limiting через INCR с TTL - защита API от перегрузки. Leaderboards через Sorted Sets - top-10 запрос за O(log N). Геолокация через GEO команды - найти ближайших пользователей. Каждый use case требует разной настройки memory policy и persistence.