Финал серии — про эксплуатацию Redis в бою и про трезвый выбор. Драйверы Go и Java и настройка пула соединений, что и как мониторить, типовые инциденты (latency-спайки, OOM, split-brain, шторм соединений) и их разбор. И главное — карта решений: когда Redis это правильный инструмент, а когда честнее взять полноценную БД, брокер или другое хранилище.
Redis умеет не только хранить, но и выполнять логику на сервере. Разбираем три способа программируемости: Streams с consumer groups (журнал сообщений с подтверждениями), Lua-скрипты и Redis Functions (атомарные серверные процедуры), плюс обзор модулей. Честно проводим границу Streams vs Kafka — где Redis Streams достаточно, а где нужна полноценная брокерная платформа.
Redis держит данные в оперативной памяти — значит, память рано или поздно закончится. Разбираем, что происходит на границе: как устроен аллокатор и откуда берётся фрагментация, какие есть политики вытеснения (LRU/LFU/по TTL/noeviction), что значит upper bound через maxmemory и что делает Redis при OOM. Плюс инструменты диагностики: MEMORY DOCTOR, INFO memory.
Один Redis — это одно ядро и один узел отказа. Разбираем, как из него собирают распределённую систему: асинхронная репликация, автоматический failover через Sentinel, шардирование по hash slots в Cluster. И честно про цену: асинхронность означает возможную потерю подтверждённых записей, split-brain реален, а Sentinel — не консенсус-протокол уровня Raft. Команда WAIT смещает границу, но не отменяет её.
WAL как источник изменений: физическая репликация (стриминг WAL) против логической (декодирование в события), CDC через Debezium (чтение WAL/binlog/oplog), PITR через WAL archiving — и подводные камни: переполнение слотов, retention, идемпотентность потребителя
Разложить данные по узлам — самая простая часть. Дальше начинается счёт: запрос без ключа шардирования идёт во все шарды, join между по-разному распределёнными таблицами Citus по умолчанию вообще отказывается планировать, глубокая страница тащит с шардов сотни тысяч строк ради двадцати, а добавленный узел сам по себе не берёт на себя ни одного шарда. Всё — замерами на живом кластере Citus
Redis умеет переживать перезапуск — но насколько надёжно? Разбираем два механизма персистентности честно: RDB-снимки, AOF-журнал, гибридный режим и политики fsync. Главный вопрос статьи — что именно теряется при сбое и почему Redis по умолчанию ближе к кэшу, чем к источнику истины. Проводим границу durability явно, а не на ощущениях.
Один принцип write-ahead, разные реализации: PostgreSQL WAL, MySQL redo log плюс binlog (две роли), MongoDB journal и oplog, Tarantool WAL и snapshot, SQLite WAL-mode, Redis AOF и WAL в LSM-движках — что общего и чем различаются
Redis обрабатывает команды в одном потоке — и при этом отдаёт сотни тысяч операций в секунду. Разбираем, почему single-threaded не значит медленно: событийный цикл, I/O-мультиплексирование, threaded I/O в новых версиях, пайплайнинг. И честно про обратную сторону: где один поток становится узким местом и откуда берётся хвостовая latency.
Write-ahead logging как фундамент надёжности: сначала журнал, потом данные; durability и crash recovery (redo/undo), checkpoints, fsync и group commit — и во что обходится эта гарантия и что она покупает
Ближайшие материалы, которые продолжают этот раздел.
Вводный материал про Redis как класс решений: паттерны, анти-паттерны, ограничения и подходы к надёжности.
Практический baseline для PostgreSQL в контейнерах: volume, backup, healthcheck и границы допустимого production.
Разбор dev- и lab-сценариев для ClickHouse и того, где контейнеризация уже начинает мешать эксплуатации.
