Практикум: когда при сбое Redis стоит продолжать работу¶
Запускаемые сценарии из статьи.
Нужен работающий Docker. Скрипты создают и удаляют собственные контейнеры Redis;
к существующей базе и платёжному провайдеру они не подключаются. Команды выполняются
из каталога docs/blog/lab/2026-09-07-when-should-redis-fail-open в клоне репозитория:
uv run --no-project --python 3.13 --with-requirements requirements.txt retry_probe.py
uv run --no-project --python 3.13 --with-requirements requirements.txt fail_open_lab.py
В requirements.txt закреплены redis-client-kit 0.3.0, redis-py 8.1.0
и testcontainers 4.15.0. Образ Redis: redis:7-alpine; скрипты выводят
версию сервера (7.4.11 в проверенном запуске).
shop.py содержит функции из обеих языковых версий статьи.
В fail_open_lab.py вместо PostgreSQL используется счётчик чтений с фиксированным
ответом, а вместо платёжного API учебная реализация с идемпотентными списаниями
в памяти. Они позволяют наблюдать чтения и списания, но не проверяют реальную интеграцию.
Практикум проверяет использование кеша и запасного источника, конкурентные попытки входа и истечение счётчика, одновременные попытки оплаты, потерю ответа после списания, отмену запроса, ограничение нагрузки на БД, отказ подключения, зависший Redis, занятый пул и восстановление с прежним клиентом. После истечения ключа допуска Redis от повторного списания защищает только моделируемый контракт провайдера. Для отдельных проверок TTL ключей сокращается, чтобы не ждать целое окно.
retry_probe.py сравнивает попытку без повторов, два повтора без общего лимита
и те же повторы с общим лимитом 0,15 секунды. Приостановка контейнера задерживает ответы
на команды, в том числе по уже установленным соединениям. Отдельный зарезервированный
порт без слушающего сервера проверяет ситуацию, когда соединение установить нельзя.
При нарушении проверяемого условия скрипт падает, при успехе выводит PASS.
Время зависит от машины и планировщика; таймауты подобраны для примера
и не являются целевыми показателями производительности.