Программа курса

Модуль 06 / Урок 27 из 27

Чек-лист «Redis в проде» и финальный проект

Теория и практика

Курс подходит к концу: собираем всё в рабочий чек-лист и финальный проект, объединяющий все шесть модулей.

Чек-лист продакшена

Память и данные

  • ☑ maxmemory задан (70–80% RAM хоста), политика eviction осознанная (allkeys-lfu для кеша).
  • ☑ У всех временных ключей есть TTL с джиттером.
  • ☑ Ключи именованы по конвенции тип:id:поле; есть инвентарь префиксов.
  • ☑ Нет big keys (алерты на размер коллекций) и гигантских значений.

Надёжность

  • ☑ Персистентность выбрана по требованию (кеш — RDB; данные — AOF everysec).
  • ☑ Реплики есть; min-replicas-to-write настроен; lag мониторится.
  • ☑ Бэкапы уходят вне сервера и проверяются восстановлением.
  • ☑ Runbook: дизастер-план с измеренными RPO/RTO (урок 4.4).

Клиенты

  • ☑ Пулы соединений, таймауты, ретраи с бэкоффом, обработка OOM/NOAUTH/MOVED/READONLY.
  • ☑ Батчирование/пайплайны там, где много операций; нет KEYS/FLUSHALL в коде.
  • ☑ Stampede-защита на горячих ключах (мьютекс/прогрев/stale-while-revalidate).

Безопасность

  • ☑ bind закрыт, protected-mode on, ACL-пользователи вместо default.
  • ☑ Опасные команды запрещены (ACL/rename); TLS по риск-модели.
  • ☑ THP выключен, overcommit=1, swappiness низкий, ulimit достаточен.

Наблюдаемость

  • ☑ Дашборд: память, hit rate, evictions, p99, fork_usec, lag, соединения (урок 6.1).
  • ☑ Алерты из таблицы 6.1 работают и проверены инцидент-симуляцией.
  • ☑ Slowlog и latency monitor включены; playbook расследования написан.

Финальный проект: «мини-система»

Соберите сервис, объединяющий все модули. Роли Redis в одном приложении:

  1. Кеш (модуль 2): cache-aside с TTL+джиттером, мьютекс против stampede, null-кеширование, hit rate в метриках;
  2. Очереди (модуль 3): фоновые задачи через Streams + consumer groups, ретраи, DLQ, идемпотентные обработчики;
  3. Координация (модуль 3): лидерство подов для планировщика через SET NX + продление;
  4. Rate-limiter (модуль 5): Lua-скрипт фиксированного или скользящего окна на каждый API-ключ;
  5. Инфраструктура (модуль 4): master + реплика + 3 Sentinel, AOF everysec, крон-бэкап с оффсайтом и проверкой восстановления;
  6. Наблюдаемость (модуль 6): exporter + дашборд + 5 алертов + playbook;
  7. Нагрузочный тест (модуль 5): memtier на 10 минут, письменный разбор: где узкое место, что бы вы масштабировали первым и почему.
🎓 Пройдя проект, вы умеете фактически всё, что обещает коммерческий курс: решать задачи Redis'ом от кеша до очередей, обеспечивать надёжность, масштабировать и диагностировать прод.

Что читать дальше

  • redis.io — документация: разделы Persistence, Replication, Cluster, Latency, Topics;
  • «Redis in Action» (J. Carlson) — паттерны применения с кодом;
  • Блог Antirez — эссе автора Redis о дизайне: latency, event loop, эволюция;
  • Release notes Redis 7.x — Functions, multi-part AOF, sharded pub/sub, listpack;
  • Исходники Redis — на удивление читаемые; t_hash.c, t_zset.c ответят на вопросы «как внутри» глубже любого курса.

Самопроверка курса

20 вопросов по всем модулям (разверните)

1. Почему медленная команда тормозит всех? — однопоточное исполнение.

2. Зачем прогрессивный рехешинг? — без «ступеньки» задержки при росте словаря.

3. Кодировка маленького hash? — listpack.

4. Чем SCAN лучше KEYS? — курсорный обход O(1) за вызов, без блокировки.

5. Что снимает TTL: SET или HSET? — SET; HSET TTL сохраняет.

6. Политика кеша по умолчанию? — allkeys-lfu (обоснованно) vs noeviction (фабричный дефолт).

7. Три защиты от stampede? — мьютекс, джиттер/прогрев, stale-while-revalidate.

8. Почему Pub/Sub не очередь? — нет хранения/ACK/ретраев.

9. За что отвечает PEL? — недоставленные ACK записи группы.

10. Что перехватывает XAUTOCLAIM? — зависшие (idle > порога) записи группы.

11. Обязательные элементы блокировки? — NX, EX(TTL), владелец, Lua-разблокировка.

12. Откуда COW-рост памяти? — fork при BGSAVE/rewrite.

13. Потеря на everysec? — ≤1с.

14. Почему failover теряет хвост? — асинхронная репликация.

15. Сколько хеш-слотов? — 16384.

16. Хеш-теги для чего? — со-размещение ключей в один слот.

17. Пайплайн даёт атомарность? — нет, только батч-отправку.

18. WATCH — что за механизм? — оптимистичная блокировка: EXEC nil при изменении.

19. mem_fragmentation_ratio < 1? — своп — критично.

20. Реплика спасает от FLUSHALL? — нет, только бэкапы.