О, вот тоже думаю в качестве брокера сообщения кафку бахнуть или Rabbit

А он не может?

До недавнего времени очень тормознуто из-за виртуальной машины, сейчас с jit стало получше

Кафка - монстр, один зоокипер чего стоит, потому юзаем редис- та ж очередь, один брокер, много консьюмеров. Ну или реббит

Канал навального может потерять owner'а из-за простоя создателя

В своё время для быстрой математики для него писали отдельные функции на си и пихали в ядро. Потом внешние программы вызывали.

Ну так много где делали

Имхо реббит больше подходит как брокер, а redis, как хранилище кэша и очередей

Истинно так

Но всё вместе, получается зоопарк и куча точек отказа, так что с этим надо очень аккуратно

Да, но у него это вообще стало штатным механизмом. Не можешь написать на эрланге чтоб быстро? Пиши на чём хочешь @ пихай в ядро или подключай как ноду

К счастью, подходящие биндинги нынче есть почти для любого говноязыка

Мы батчим паки запросов в кеш, есть ключ автоинкремента последней не обработанной таски, есть сами таски кучей, получается консьюмеры как освобождаются сразу читают таску и инкрементируют атомарно значение номера таски.
Так как у нас это для аналитики, где время обработки батча почти всегда долгое (парсит и кладет в бд), то редис вполне себе работает.
Но да, были косяки когда редис падал, решили поднятием редис кластера из 3 мастеров и 3 преднагретых ноды. Так как в докере и волюмы надо куда то маунтить - ещё и ceph  подняли, вот этот гад жрет cpu как не в себя.
Да, может мы тупые, но хотели быстро релизнуть и в принципе получили

Кстати, недавно тут проскакивала рекламка проекта на замену ceph, оч интересно выглядела и явно полегче

Прошу прощения у сообщества если я оффтоплю и гоню личную экспу

Да нет, звучит нормально. Я бы глянул узкие места, может и не пришлось бы столько мощностей тратить

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

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

abslimit [xmpp] https://f.xmpp.netwhood.online/d53dbf89dbedefe81861f688731a7ab24ad75f9f/HKqAYefAzITDQIs9JXAgWcxpfM4lwRpZyH3xPvywEQKFRCzR/1bbfb3e448a8f18d.jpg

Почти так :) юзеры постят всякое в чат, парсить сразу дорого, в рантайме им доступна история из 1к сообщений, все что дальше периодически кидаем в редис, вот там  то и работает описанная выше схема для аналитики - мусор выкидыааем, что надо сохраняем в постгри для истории и метриками Прометея если кому надо "графики прямо сейчас"
Если интересно - пишите в личку:)