RabbitMQ как инструмент «деградации с честью»

[Grand_piano]

Ничего не понятно, но очень интересно.

[OlegIct]

🤝 Тоже мало что понял, особенно про PostgreSQL и как он относится к теме. «Яд» это, наверное, что-то похожее на poisoning в очередях сообщений (сообщение, которое не потребляется, а только тратит ресурсы обработчиков на попытки его потребить). Обычно, настраивают очередь так, чтобы по истечение срока нахождения в очереди (TTL), такое сообщение переносилось в error queue, где разбиралось вручную. Или настраивают селекторы, чтобы обработчик не пытался потребить сообщение, которое не может обработать.

Может автор немного упростит статью, опишет что значат термины и статья станет понятнее непосвященным 🙂

[luvgreyair]

Хорошая идея, может вскоре и сам кейс получится предметно показать и рассказать, так что включаем уведомления!

[KoIIIeY]

create index on outbox (status, next_retry_at);

Такой индекс работает?

[luvgreyair]

Да, создастся, но толку мало. Лучше отдельные частичные индексы под new и failed - так быстрее работает

[KoIIIeY]

Я понимаю что создастся, я не понимаю зачем на дату время ретрая, оно же близко к уникальному будет

[luvgreyair]

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

p.s. надеюсь я правильно понял вопрос

[pkokoshnikov]

И на какую нагрузку рассчитано всё это? Очередь в postgres довольно узкое место будет

[luvgreyair]

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

[pkokoshnikov]

Просто если речь про rps < 1000, то о какой деградации идёт речь? На таких объёмах проще все синхронно делать не те объёмы. Если же rps > 1000 то с постгресом тут будет очень сложно. Проще outbox сделать в rabbit, а уже оттуда при чтении делать несколько транзакций в разных системах хоть синхронно хоть асинхронно. Outbox на базе очень узкоспециализированный кейс.

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

[luvgreyair]

Согласен, на rps < 1000 проще жить синхронно. Но когда нагрузка улетает в десятки тысяч событий - синхрон начинает разваливаться: таймауты, каскадные фейлы. Вот там outbox + брокер и вывозят, иначе бизнес-операции просто ложатся

[tkutru]

"Деградация с честью" - похоже, ещё никто до этого так не обзывал graceful degradation... Можно было бы написать плавная, изящная.

[budnikovsergey]

а можно ли обойтись kafka вместо rabbitmq? managed rabbitmq особо не наблюдается в облаках в отличие от kafka

[luvgreyair]

Можно, но кафка сложнее в эксплуатации. Рэббит проще как буфер для outbox

[BakinSergey]

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