Вы блять шутите: представьте, очередь с auto-delete, такая же, как 4000 других на этом же RMQ, на которых от 1 до 10 консьюмеров
Но когда именно на ней 4 consumer, все ок, добавляется такойже 5 и она моментально удаляется...
По всем логам и метрикам всех сервисов, железок и узлов все абсолютно ок
Как починили? Перезапустили ноды самого RMQ и оно заработало...
Ну как нахер так...
По какому принципу он может удалять 1 конкуретную очередь пока ты не перезагрузишь сам RMQ?
Это не ошибка кода, потому что (исключая то, что мы максимально прямолинейно с ним общаемся) она бы тогда повторилась и при перезагрузке
Это ошибка в "battle-tested" технологии, которая обязана гарантировать 1 свою главную обязанность - доставлять данные от паблишера консьюмеру по объявленным очередям
Вы знаете что о такой ситуации пишут в коммьюнити? Переходите на quorum очереди
А знаете что такое quorum очереди? Это очереди с кластеризованным персистентным хранилищем (Kafka, без лога)
Почему это сработает? Потому что тогда ответственность за очередь распределяется на кластер и есть шанс, что одна нода не позволит другой навредить очереди
Но, во-первых, суть блять взятия RMQ была именно в том, что нас в этих очередях не нужна персистентность, нас интересовала скорость с гарантией последовательности, во-вторых, почему кластеризация должна решать вопрос ошибок в кор механике самой системы не давая ей самостоятельно удалить вашу очередь «просто-потому что»
По факту они предлагают делать латентную версию Kafka, чтобы просто повысить шанс, что RMQ не трахнет вас очередным внутренним багом...
P.S.
Когда я все это написал я понял что вымораживает меня больше всего и заколачивает последний гвоздь гроба RMQ:
После удаления очереди эта сука не только НЕ ПРИСЛАЛ ОШИБКУ, так ещё эта гнида ПРОДОЛЖАЛА ДЕРЖАТЬ ОТКРЫТЫЕ КАНАЛЫ на эту очередь
Мы смогли продебажить и увидели, что это не приложение продолжало держать каналы, а сам RMQ
И он воообще ничего нам не сообщил, ни ошибки, ни инфы о смерти очереди
Вот этому нет никакого оправдания
P.P.S.
Я до сих пор в таком шоке, что я надеюсь, что это мы где-то накосепорили и всему этому есть объяснение, потому что ну как тогда вообще можно использовать RMQ, если он может такое вытворять (а используют его многие)
Если ситуация повторится и мы получим больше инфы, я напишу
V
Vassiliy ИТК Kuzenkov
2023-10-22 09:53
я чет всю жизнь успешно избегал кролика )
A
Arsen ИТ-К Arakelyan
2023-10-22 10:01
А что юзал Kafka? Или ты избегал микросервисов?
V
Vassiliy ИТК Kuzenkov
2023-10-22 10:03
да, я в микросервисную движуху никогда не вписывался )
очереди только для воркеров, бг джоб и всякого процессинга. Redis + Bull обычно, пробовал на одном проекте SQS Амазоновский
A
Arsen ИТ-К Arakelyan
2023-10-22 10:09
А объясни плиз бг джоб?
A
Arsen ИТ-К Arakelyan
2023-10-22 10:11
Никогда не было интересно или не нужно было на самом деле?
Смотрел Кирилла, который рассказывал что микросервисы это в первую очередь организационное решение вынужденное из-за большого количества команд и сервисов которые лучше разделить просто чтобы было проще мониторить в разных репах, чем 1 монолит.
Хотя с точки зрения инфраструктуры это намного сложнеее
V
Vassiliy ИТК Kuzenkov
2023-10-22 10:18
Никогда не возникало нужды. Так как я и процессы в самой компании организовываю и на проектах - всегда стремлюсь, чтобы все было возможно поддерживать небольшим числом людей с нужным фокусом.
Инфраструктурно-технически однозначно сложнее. Однозначно дороже и однозначно трудозатратнее.
Как бы иметь пачку сервисов на других технологиях - потому что так удобнее/оптимальнее. Тут да, сервисы отдельно висят. Даже через sqs вот общались. )
A
Arsen ИТ-К Arakelyan
2023-10-22 10:20
А как те serverless пробовали на проектах?
V
Vassiliy ИТК Kuzenkov
2023-10-22 10:24
Приходили легаси решения. Ну такое). В serverless фреймворке (который вот основной) - все намешано и конфигурация инфры с клаудформейшеном и лямбды и плагины. Потом собираешь эти ямлы. Что конечно вносит свой странный привкус 💩 когда на нем пишешь. ) Хотя в целом все там неплохо. Но скорее на любителя Ну и если брать конечные косты, то выходит довольно дешево для стартапов, которые проверяют гипотезу и скорее умрут. И как-то не очень дешево если нет. Опять же есть точечные крутые юзкейсы лямбд, когда, например, нужно что-то внутри авса исполнить и по вебхуку трегерить (сложнее чем пачку cli команд)
A
Arsen ИТ-К Arakelyan
2023-10-22 10:26
Да, согласен, или если нужна пачка функций по генеру доков/отчетов которые если делать на EC2 с круглосуточным пэйментом дофига получится, а сделать пару лямбд супер дешево и достаточно быстро учитывая что это внутренняя корпо штука)
Корпо юзеры могут и подождать🤣
V
Vassiliy ИТК Kuzenkov
2023-10-22 10:31
Мы обычно ecs поднимаем c fargate. Там тоже прям копейки выходят. Но тут у лямбд тоже есть ниша, согласен.
🦾
🦾 IT-Качалка Давида Шекунца 💪
2023-10-22 11:01
Счастливый человек…
В прошлом я использовал его чаще всего для процессинга всех сообщений, поэтому имел смысл quorum, поэтому все работало, но неоптимально, поэтому в итоге мы пересаживались на Kafka
Сейчас суть была скорее в очереди формата pub/sub
И RMQ это именно оно, но блять…
Кстати продолжение дебагинга показывает что RMQ просто не умеет в нормальный fail-over при разрыве сети
Y
YURII VLADIMIROVICH
2023-10-22 11:33
Привет, что тебе дев опс сказал ? Что там за хлам ?
На сколько образ уже сократил?
🦾
🦾 IT-Качалка Давида Шекунца 💪
2023-10-22 12:05
Уже было тогда поздно, а сейчас выходные, поэтому пока оставил вопрос на следующую неделю