Структуры данных Redis на практике
Предпосылки: Клиенты и соединения, STRING, HASH, LIST, SET, ZSET, Stream, HyperLogLog, Bitmap, Sub, EXEC.
← Клиенты и соединения | Команды, блокирующие Redis →
Структуру Redis выбирают не по сходству с предметной областью, а по минимальному набору операций, который нужен приложению. Нужен TTL и атомарный счётчик — STRING. Нужны частичные обновления одного объекта — HASH. Нужны порядок и блокирующее ожидание — LIST. Нужны приоритеты и ранги — ZSET. Нужна рассылка всем процессам — Pub/Sub. Нужны история и подтверждение обработки — Stream.
Ниже — конкретные Rails-сценарии, сгруппированные от простых операций с одним ключом к координации между процессами.
Почти в каждом сценарии Redis закрывает не только локальную задачу структуры данных, но и системный trade-off: rate limiting, когерентность локального кэша, sub, acknowledgment и гарантии доставки.
Одно значение, один ключ. Rate limiter на STRING — атомарный счётчик с TTL для ограничения запросов партнёров. Корзина checkout на HASH — несколько полей заказа, обновляемых независимо без гонки. Ограниченный лог активности на LIST — LPUSH + LTRIM для хранения последних N действий.
Коллекции и очереди. Очередь email на LIST — FIFO с блокирующим ожиданием через BRPOP (используется в Sidekiq). Очередь звонков на ZSET — приоритеты, позиция в очереди, удаление из середины за O(log n). Права доступа на SET — O(1) проверка принадлежности и серверные пересечения/объединения ролей.
Аналитика и счётчики. Уникальные посетители на HyperLogLog — 12 КБ на счётчик вместо десятков мегабайт в SET. DAU и retention на Bitmap — 1.25 МБ на день при 10 миллионах пользователей, серверные BITOP AND/OR.
Координация и гарантии. Аудит-лог платежей на Stream — consumer groups для параллельной обработки несколькими сервисами с гарантией at-least-once (каждое сообщение доставлено хотя бы один раз). EXEC — оптимистичная блокировка с WATCH и retry. Распределённая блокировка на STRING — SET NX EX + Lua для защиты от двойной обработки Sidekiq-джобов. Защита от cache stampede — блокировка на перестроение и early expiration.
Межпроцессная рассылка. Sub — рассылка всем Puma-воркерам без подтверждений и без хранения истории. Sub — координация WebSocket’ов между Puma-процессами через Redis-подписку.