Redis в Rails-приложении
Предпосылки: Redis как сервер структур данных (архитектура, структуры данных, персистентность, eviction), конкурентность в Ruby (GVL, потоки, I/O-конкурентность), Puma (воркеры + потоки).
Rails-приложение на Puma — это несколько процессов, в каждом несколько потоков. Процессы изолированы: у них нет общей памяти. Redis становится общим хранилищем состояния, доступным всем процессам по сети: кеш, сессии, счётчики, координация WebSocket’ов, фоновые задачи.
Серия читается в два прохода. Сначала — как Rails вообще разговаривает с Redis: короткие обращения из веб-запроса через пул соединений и отдельные долгоживущие соединения для подписчиков, блокирующих очередей и фоновых воркеров. Потом — выбор структуры данных под конкретную операцию: одно значение, частичное обновление объекта, очередь, приоритет, рассылка всем процессам, журнал событий.
За этими рецептами стоят общие концепции из system design: когерентность кэша, cache stampede, temporal decoupling, Sub, гарантии доставки и idempotency.
Содержание
Клиенты и соединения — redis-rb, hiredis-client, connection_pool, конфигурация нескольких инстансов Redis под разные задачи.
Структуры данных на практике — карта выбора: STRING, HASH, LIST, SET, ZSET, Stream, Bitmap, HyperLogLog и Pub/Sub на конкретных Rails-сценариях из practice/.
Команды, блокирующие Redis — какие команды блокируют event loop и как этого избежать в Rails-коде.
Связанные заметки
- Sidekiq — фоновые задачи через Redis LIST + BRPOP
- Кэширование — когерентность, инвалидация, stampede
- Очереди сообщений — acknowledgment, point-to-point vs pub/sub, лог vs очередь
- Гарантии доставки — at-most-once, at-least-once, exactly-once
- Паттерны надёжности — retry, backoff, idempotency, bulkhead