Какой опыт работы с Redis, его структурами данных, pub/sub и стримами

Что проверяют

Понимаете ли вы, какая структура Redis подходит под задачу и какие гарантии доставки дают pub/sub и стримы. Главный уточняющий вопрос почти всегда один: что будет с сообщением, если подписчик в этот момент лежал.

Как отвечать

Структуры данных называйте сразу с задачей:

• строки: кэш, счётчики через INCR, блокировка через SET key value NX PX 30000;
• хэши: объект с полями и частичным обновлением через HSET;
• списки: простая очередь на LPUSH и BRPOP, но задача теряется, если воркер упал после чтения. BLMOVE в список «в работе» это исправляет;
• множества и отсортированные множества: уникальные значения, рейтинги, лимит запросов по скользящему окну через ZADD и ZREMRANGEBYSCORE.

Pub/sub работает по принципу «отправил и забыл»: сообщение получают только те, кто подписан прямо сейчас, ничего не хранится. Подходит для инвалидации кэша между инстансами или адаптера Socket.IO. Соединение в режиме подписки не выполняет обычные команды, поэтому в ioredis и node-redis для него заводят отдельный клиент через duplicate().

Стримы хранят историю: XADD пишет, XREADGROUP читает в группе потребителей, сообщение лежит в pending до XACK. Сообщения упавшего воркера забирают через XAUTOCLAIM, длину стрима ограничивают через MAXLEN. Для очередей задач в Node.js обычно берут BullMQ, он работает поверх Redis.

Добавьте эксплуатацию: maxmemory и политика вытеснения, RDB и AOF, Redis Cluster с 16 384 слотами. Опирайтесь на свой пример и честно оговорите, если стримы знаете только по документации.

Где спотыкаются

Строят на pub/sub доставку, которая не должна терять сообщения, и рассказывают про «повторную отправку», которой в pub/sub нет.

Выполняют KEYS * на проде. Команда блокирует однопоточный Redis на всё время обхода, нужен SCAN.

Забывают про XACK и не разбирают pending: список неподтверждённых сообщений растёт, а задачи упавших воркеров так никто и не обработает.