7.6Вытеснение, персистентность, отказоустойчивость

Выбери Redis-настройки исходя из роли данных: вытеснение, RDB/AOF и Sentinel/Cluster дают разные свойства. Пойми, какие записи можно потерять при каждом механизме и почему Redis как кэш не должен быть единственной копией критичного состояния.

maxmemory и политики вытеснения

maxmemory задаёт верхнюю границу памяти под данные. Что делать, когда она достигнута, решает maxmemory-policy. Её восемь классических вариантов делятся на три семейства (с Redis 8.6 добавились ещё allkeys-lrm и volatile-lrm, они вытесняют по давности последней записи): ничего не выбрасывать, выбрасывать из всех ключей (allkeys-*) или только из тех, у кого выставлен TTL (volatile-*).

LRU против LFU

LRU выбрасывает то, к чему дольше всего не обращались, а LFU то, к чему обращались реже всего. Разница видна на конкретном профиле нагрузки: LRU ломается на «сканирующем» трафике, когда поток разовых обращений вытесняет устойчиво горячие ключи.

Как Redis приближает LRU

Настоящий LRU требует двусвязного списка всех ключей: при каждом обращении элемент переносится в голову. Это два указателя на объект (16 байт на ключ только под учёт) плюс работа на каждом GET. Для базы на десятки миллионов ключей такое неприемлемо, поэтому Redis реализует не LRU, а его аппроксимацию.

• В заголовке каждого объекта есть 24-битное поле lru с «часами»: временем последнего обращения с грубым разрешением. Никакого списка, никаких указателей.
• Когда нужно вытеснять, Redis берёт случайную выборку из maxmemory-samples ключей (по умолчанию 5) и выбрасывает лучшего кандидата в ней.
• С Redis 3.0 есть ещё пул кандидатов на 16 элементов: лучшие жертвы из разных выборок копятся между вызовами, и при той же цене результат заметно ближе к идеальному LRU.
• maxmemory-samples 10 даёт результат, практически неотличимый от точного LRU, но ест больше CPU; 3 работает быстрее и грубее.

LFU устроен похоже, только в тех же 24 битах вместо часов лежат 8-битный логарифмический счётчик и 16 бит времени последнего затухания. Инкремент вероятностный: чем больше счётчик, тем реже он растёт (этим управляет lfu-log-factor), поэтому 8 бит хватает на диапазон до миллионов обращений. Со временем счётчик затухает - lfu-decay-time задаёт, за сколько минут простоя он уменьшается на единицу. Без затухания LFU был бы фатально консервативным: вчерашний хит вечно вытеснял бы сегодняшний.

Персистентность: RDB и AOF

Redis хранит данные в памяти, а при перезапуске процесса память пуста. Персистентность нужна, чтобы поднять данные обратно после рестарта: копия памяти регулярно уходит на диск. Механизмов два, они независимы, и включать можно любой, оба или ни одного.

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

appendfsync - где именно теряются данные

Запись в AOF мгновенно попадает в буфер ядра, а на диск данные уходят только при fsync. Как часто он вызывается, определяет appendfsync, и она же задаёт размер окна потери.

Гибридный режим

С Redis 4.0 есть aof-use-rdb-preamble yes (в современных версиях включён по умолчанию): при перезаписи AOF основой журнала становится RDB-снимок, а команды, пришедшие позже, дописываются после него. До Redis 7.0 это был один файл: снимок в начале, команды следом. С 7.0 AOF — это каталог: базовый файл со снимком, файлы с командами после него и манифест, который задаёт порядок их чтения. От RDB берутся компактность и быстрый старт, от AOF минимальная потеря. Поэтому на «что выбрать» правильно отвечать так: оба, в гибридном режиме.

Есть ещё AOF rewrite. Журнал растёт бесконечно (миллион INCR даёт миллион строк), поэтому Redis периодически перезаписывает его в компактную форму, отражающую текущее состояние. Rewrite идёт через fork(), с тем же copy-on-write и тем же риском скачка памяти, что и BGSAVE. Настраивают его через auto-aof-rewrite-percentage и auto-aof-rewrite-min-size.

Репликация, Sentinel, Cluster

Репликация - асинхронная

Мастер принимает записи и потоком отправляет их репликам, причём асинхронно: клиенту он отвечает OK, не дожидаясь подтверждения от реплик. Отсюда прямое следствие, которое и хотят услышать: подтверждённая запись может быть потеряна, если мастер упадёт до того, как реплика её получит, а failover поднимет эту реплику.

• Начальная синхронизация: BGSAVE на мастере, передача RDB, затем поток команд. После разрыва, если реплика отстала не слишком сильно, хватает частичной ресинхронизации по буферу repl-backlog.
• Реплики по умолчанию доступны только на чтение (replica-read-only yes). Данные на них отстают на величину лага, так что read-your-writes не гарантирован.
• Команда WAIT numreplicas timeout блокирует до подтверждения записи N репликами. Это не синхронная репликация и не транзакционная гарантия: она не откатывает запись при неуспехе, а лишь сообщает, сколько реплик подтвердили. Полезна как «барьер» перед критичным действием, но строгой durability не даёт.
• Настройки min-replicas-to-write / min-replicas-max-lag заставляют мастера отказывать в записи, если у него меньше N живых реплик. Так доступность меняют на меньший риск потери, то есть сдвигаются в сторону CP.

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

Sentinel состоит из отдельных процессов-наблюдателей (нечётное число, минимум три), которые следят за мастером и репликами. По шагам:

1. Мониторинг. Каждый sentinel пингует мастера и, если тот молчит дольше down-after-milliseconds, помечает его субъективно недоступным (SDOWN).
2. Кворум. Кворум нужен, чтобы один потерявший сеть наблюдатель не мог единолично объявить мастера мёртвым. Sentinel опрашивает остальных, и если о недоступности заявили не меньше quorum из них, статус повышается до объективно недоступного (ODOWN).
3. Выборы лидера. Sentinel-ы выбирают среди себя лидера (вариант Raft), который проведёт failover. Для выборов нужно большинство sentinel-ов - и это важнее кворума: при трёх sentinel-ах нужны два живых.
4. Промоушен. Лидер выбирает лучшую реплику (по приоритету, объёму полученных данных, run id), делает ей REPLICAOF NO ONE, перенастраивает остальные реплики на неё и обновляет конфигурацию.
5. Уведомление клиентов. Клиенты спрашивают у Sentinel адрес текущего мастера, а команды шлют уже ему напрямую. В go-redis для этого есть NewFailoverClient.

Redis Cluster и 16384 слота

Sentinel даёт отказоустойчивость, но не горизонтальное масштабирование: весь датасет всё равно лежит на одном мастере. Cluster шардирует данные между несколькими мастерами, у каждого из которых свои реплики.

• Пространство ключей разбито на 16384 слота. Слот ключа считается как CRC16(key) mod 16384. Каждый мастер владеет диапазоном слотов.
• Почему 16384, а не 65536: карта слотов входит в каждое сообщение протокола gossip как битовая маска. 16384 бита занимают 2 КБ на сообщение, а 65536 заняли бы уже 8 КБ. При типичном размере кластера в десятки нод такой размер избыточен, а 16384 хватает с запасом.
• Клиент сам знает карту слотов и ходит сразу на нужную ноду. Прокси нет: шардинг клиентский, и протокол его поддерживает.

Ограничения кластера

• Мультиключевые операции только внутри слота. MGET, MSET, SUNION, ZUNIONSTORE, транзакции и Lua-скрипты требуют, чтобы все ключи хешировались в один слот, иначе CROSSSLOT. Клиенты вроде go-redis умеют разбивать MGET на несколько запросов по нодам, но атомарности при этом нет.
• Hash tag режет в обе стороны. {userID} в ключе сводит все данные пользователя в один слот и делает возможными транзакции и Lua. Но если тег выбран неудачно (например, {tenant} у крупного клиента), весь его объём и трафик приземляются на одну ноду, то есть ты своими руками создал горячий слот.
• Нет баз данных. В кластере доступна только db 0, SELECT не работает.
• Pub/sub. Классический pub/sub в кластере рассылается по всем нодам (что дорого); с Redis 7 есть шардированный pub/sub SPUBLISH/SSUBSCRIBE, привязанный к слоту канала.
• Failover внутри кластера обходится без Sentinel: реплики сами инициируют выборы, решение принимает большинство мастеров. Если мастер потерял свои слоты и реплики нет, кластер по умолчанию (cluster-require-full-coverage yes) перестаёт обслуживать все запросы, а не только этот диапазон.

Почему Redis не даёт строгих гарантий

1. Данные могут исчезнуть по политике вытеснения. При allkeys-* Redis имеет полное право выбросить любой твой ключ до истечения TTL. Значит, приложение обязано корректно работать без ключа в любой момент.
2. Данные могут потеряться при падении. При everysec пропадёт до секунды записей, без AOF всё с последнего снимка.
3. Подтверждённая запись может потеряться при failover. Репликация асинхронная; окно между ответом клиенту и доставкой реплике не защищено ничем.
4. Возможен split brain. Старый мастер в изолированном сегменте продолжает принимать записи, которые потом будут отброшены.
5. Транзакции не такие, как в БД. MULTI/EXEC даёт атомарность выполнения и изоляцию (команды идут подряд без чужих между ними), но не даёт отката: если одна команда упала на этапе выполнения, остальные всё равно выполнятся.

> MGET user:42:profile user:43:profile
(error) CROSSSLOT Keys in request don't hash to the same slot

# Без тега слоты разные:
user:42:profile   -> CRC16("user:42:profile") mod 16384
user:42:orders    -> CRC16("user:42:orders")  mod 16384

# С тегом CRC16 берётся только от того, что внутри первых фигурных скобок:
user:{42}:profile -> CRC16("42") mod 16384
user:{42}:orders  -> CRC16("42") mod 16384      # тот же слот
> MGET user:{42}:profile user:{42}:orders       # работает
> EVAL "..." 2 user:{42}:profile user:{42}:orders   # тоже работает

Что стоит запомнить

• maxmemory policy определяет, что Redis делает при нехватке памяти; noeviction превращает запись в ошибку вместо вытеснения.
• RDB и AOF различаются формой сохранения и окном потери; репликация сама по себе не равна резервной копии.
• Sentinel и Cluster решают разные задачи управления доступностью и распределением ключей.

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

• Не полагайся на volatile-* политику, если у ключей нет TTL: вытеснять может быть нечего.
• Не считай подтверждение записи репликой гарантией сохранения при failover без учёта асинхронности.
• Не включай AOF/RDB, не определив допустимое окно потери, восстановление и влияние фонового fork на ресурсы.

save 300 10
appendonly no

maxmemory 256mb
maxmemory-policy noeviction
save 300 10
appendonly no