Redis streams кто-нибудь юзал?

Streams не видел, но у обычного редиса в моем опыте были проблемы с надежностью. Теряет соообщения, репликация не спасает от этого ибо асинхронная (была тогда). Почему не rabbitMq? Имхо редис все таки для другого, а очереди надо делать в специальных сервисах. У раббита тоже не идеально, но есть quorum queues

Это скорее всего про Pub/Sub. Там нет лога сообщений, соответственно если косьюмер отваливается то сообщений он не получает.

Streams пока не трогал.

Почему не rabbitMq?

Поддерживать некому. Редис уже есть и на поддержке у провайдера. Вон с кафкой та же хрень сейчас, нет людей. Потеря сообщений фиг с ней, даже если 2-3 джобы улетят (а на наших объёмах поток небольшой) - пёс с ними, в крайнем случае есть retry на уровне запроса фронта

Не, редис правда может пролюбить сообщение. По дефолту вожатый никого не ждёт. Но если надо critical кровь из носу чтоб была репликация - её можно запросить послав wait после команды. Но этого кмк вообще никто никогда не делает, лаг обычно 1-2 сообщения

Мне кажется для этой задачи в целом брокер не нужен, можно любой субд обойтись

Можно, сейчас так и есть, на том же самом редисе на котором думаю стримы вставить.

Но это более чуть запарно ввиду наличия кастомного кода для лока на задачу и мониторинга, плюс нет возможности удобно связать sorted set и hash, либо дробить на два ключа либо пихать строкой/байтами. Ну и есть затык с ожиданием результата, в редисе к сожалению нет wait until exists, либо юзать pubsub, либо стримы, либо полл, либо городить телегу на списках и blocking pop.

Так что если можно стримами заткнуть сразу все эти дырки то было б неплохо

Мы делали атомарно с помощью Lua. Деталей не помню, уже лет 6 прошло, но было две структуры данных одна для хранения заданий, вторая для взятых в работу с датой старта (или планируемого завершения). Когда консьюмер берет задание, оно перекладывается из одной структуры в другую. Какие именно структуры не помню, но кажется одна из них список, а вторая zset, с быстрым поиском по id и получением в отсортированном виде. Когда задача выполнилась она удаляется из zset.

Отдельный процесс периодически смотрит в zset , и если видит что какие-то задачи затаймаутились то перекладывает обратно в первую очередь.

Pub/Sub не помнб почему не подошел, но делали подписку на список каким-то другим способом.

А субд не подошла потому что были тысячи рпс на вставку в эти очереди.

Поддерживать луа тоже люди нужны. А что за проблема с поддержкой? кажется что поддержка небольшого кластера кафки-раббита это не такое уж и сакральное знание и не рокет-сайнс..

Ну т.е у нас и с редисом были проблемы, кластер разваливался, не хотел с ipv6 работать и много чего еще, не скажу что раббит прям ой как сложнее.

Черт, про провайдера не увидел )

Мы делали атомарно с помощью Lua. Деталей не помню, уже лет 6 прошло, но было две структуры данных одна для хранения заданий, вторая для взятых в работу с датой старта (или планируемого завершения). Когда консьюмер берет задание, оно перекладывается из одной структуры в другую. Какие именно структуры не помню, но кажется одна из них список, а вторая zset, с быстрым поиском по id и получением в отсортированном виде. Когда задача выполнилась она удаляется из zset.

Вот 1:1 что и у нас. Прям до последней буквы

Поддерживать луа тоже люди нужны. А что за проблема с поддержкой? кажется что поддержка небольшого кластера кафки-раббита это не такое уж и сакральное знание и не рокет-сайнс..

Про кафку не согласен, её правильно настроить сложно. Плюс очень жирная, ей даже на старт нужна толстая машина. А с людьми - ну смотри, вот кафка, ей zk нужен, ещё база, ещё редис, ещё серваки с паппетом, ещё swarm или кубы, ещё редис, эластик… так можно долго продолжать.

Оно все не рокет сайнс, тот же редис поставил и он пашет. Пока не упадёт. И так со всем. В какой-то момент набираешь критическую массу когда чинить инфру приходится в ущерб прод задачам. Потому пытаемся сократить количество инфры на поддержке и что-то скинуть провайдеру (например редис или кубы).

Да , про кафку погорячился, но раббит он самодостаточный, ему ничего не надо

Хз, кролик это опять же плюс один на поддержке, плюс одна либа в коде, плюс одно что-то на никому не известном языке и т.д. Когда серьезные проблемы бывают то по опыту приходится лезть в исходники, и скажем для того же эластика знание жабы уже раза два выручало после неудачного апдейта (собирал с кастомным патчем чтоб пропустить битые данные и потом их удалить/поправить). А вот эрланг я хз, да и в команде тоже никто не знает, если придут вилы с апдейтом - будет больно.

С редисом и луа уже как-то коллеги смирились, да и тестить удобно - он мелкий, поднимаем контейнер прямо из тестов, можно сидеть дебажить вживую. С большинством mq такой финт не пройдёт.

Мне в целом пришла в голову мысль как можно попробовать провернуть очередь на стримах и пабсабе на редисе так чтоб было красиво и чисто (без трех-четырех сетов и прочих радостей), закину завтра в отдельный тред описание чтоб кто хочет кинул какашкой в сторону где что сломаться может.

Если интересно до чего пока дошёл воспаленный мозг: Вариант системы распределения задач на Redis Streams