Практикум модуля 3

Итоговая практика обмена сообщениями: собираем очередь с ретраями и DLQ, лидерство и измеряем throughput.

Задание 1. Полноценная очередь задач

Реализуйте на своём языке класс RedisQueue:

• publish(task) → XADD с MAXLEN ~ 100000;
• пул воркеров: XREADGROUP + идемпотентная обработка (дедуп по ID через SET NX);
• XACK после успеха;
• пастух: XAUTOCLAIM (idle > 2× обработки), delivery-count > 3 → XADD в tasks:dlq + XACK + XDEL;
• метрики: XLEN, длина PEL, длина DLQ.

Тесты: (1) нормальная обработка 1000 задач тремя воркерами; (2) воркер падает на 30% задач — все они через XAUTOCLAIM обрабатываются повторно и завершаются; (3) «ядовитая» задача падает всегда — оказывается в DLQ не более чем после 3 попыток.

Задание 2. Cron с выбором лидера

Два пода (процесса), job «раз в 10 секунд печатать время». Требования:

• печать ровно одна на тик, независимо от числа подов;
• убийство лидера — фолловер становится лидером за ≤ 20с;
• восстановление старого лидера не создаёт двойного лидера.

Реализация: heartbeat-схема из урока 3.4. Логи с UUID подов — доказательство выполнения требований.

Задание 3. Pub/Sub-инвалидатор

Свяжите модуль 2 и 3: SmartCache из практикума 2.5 подписывается на канал cache:invalidate; другой процесс, обновляя данные, публикует имена ключей. Проверьте, что: (1) локальные копии чистятся мгновенно; (2) при «потере» сообщения (остановите подписчика) система самовосстанавливается через TTL.

Задание 4. Throughput-замеры

# List-очередь
redis-benchmark -t lpush,lpop -n 200000 -q
# Stream
redis-benchmark -t xadd -n 200000 -d 64 -q
# Pub/Sub при 10 подписчиках (10 терминалов SUBSCRIBE ch)
redis-benchmark -t publish -n 200000 -q

Зафиксируйте цифры вашего железа и напишите 5 строк вывода: где какой механизм применим.