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