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

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

Работали ли вы с Redis дальше «положили в кэш, забрали из кэша». Вопрос поведенческий, поэтому ждут ваших случаев, а не пересказа документации. Следом углубляются в то, что вы назвали сами: почему выбрали стримы, а не pub/sub, и что делали, когда данные перестали помещаться в память.

Как отвечать

Соберите ответ вокруг задач, которые решали, и назовите структуры под них:

• строки и хеши: кэш ответов и сессии, SET key value EX 300, счётчики через атомарный INCR. Хеш экономнее набора отдельных ключей и позволяет менять одно поле;
• сортированные множества: рейтинги, окно для ограничения частоты запросов, отложенные задачи со временем в качестве score;
• множества и вероятностные структуры: уникальные посетители через HyperLogLog, 12 КБ на счётчик и погрешность около процента;
• pub/sub: широковещательная рассылка без сохранения. Подписчик, который был офлайн, сообщение не получит, подтверждений нет. Это шина уведомлений, а не очередь;
• streams: XADD, группы потребителей через XREADGROUP, подтверждение XACK, разбор зависших сообщений через XPENDING и XAUTOCLAIM. Отсюда и берётся доставка минимум один раз, которой в pub/sub нет.

Обязательно расскажите про эксплуатацию: политику вытеснения maxmemory-policy, персистентность RDB и AOF, запрет KEYS на проде в пользу SCAN, однопоточность ядра и опасность больших ключей. Про распределённую блокировку говорите точно: SET key token NX PX ttl, снятие скриптом со сверкой токена, а не голым DEL.

Приводите свои случаи с цифрами: объём данных, нагрузка, выигрыш по времени ответа.

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

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

Считают MULTI и EXEC полноценной транзакцией с откатом. Команды выполняются подряд, без вклинивания чужих, но ошибка одной из них не отменяет остальные. Атомарная логика с условиями пишется скриптом на Lua или функцией.

Не думают про память и вытеснение. Ключи без TTL при политике noeviction однажды упрутся в maxmemory, и запись начнёт возвращать ошибку, а не тихо освобождать место.