Здравствуйте, maxkar, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>В том и дело, что я хочу функцию надежной доставки возложить на этот брокер, а не городить его в каждом приложении.
M>А не получится "не городить".

Получится. Я напомню что такие продукты существуют. Но они дорогие и тяжеловесные.
Мне в одном проекте даже довелось использовать.

M>Всегда есть проблема надежно доставить сообщение от отправителя для брокера. В момент генерации сообщения может не оказаться сети. Узел брокера может внезапно умереть. На машину с отправителем сразу после коммита в базу данных (или другое persistence storage) может случайно упасть метеорит и докатывать сообщение в брокер придется уже кому-то другому. Именно это и есть основная проблема — надежно доставить от первой точки до существующего решения. А дальше распространение сообщения по цепочке — уже вопрос удобства реализации.

Госпади, как же люди с очередями работают типа rabbitmq... Они ведь тоже могут оказаться недоступны.

Давайте вопрос доступности брокера оставим за кадром.



G>>Тем более я сильно сомневаюсь в квалификации среднего программиста, что он может без ошибок сделать надежную доставку.
M>Значит нужно выбирать одно из решений, которое позволяет упросить кодирование.
Так в этом и вопрос, существует ли такое решение? Я знаю пару очень дорогих. А дешевых\беслатных не видел к сожалению.


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



M>Причем вся эта магия с брокером работает только для ситуаций, когда можно отправить сообщение и забыть про него. К сожалению, во многих случаях нужно надежно продолбиться к конкретному сервису, получить от него ответ и обработать. Там брокер не особо поможет (хотя да, можно и вокруг брокера нагородить...).
Тем не менее использование очередей очень популярно. Внезапно там не надо синхронно получать ответ.


M>В кровавом энтерпрайзе с реальными деньгами такое "отправили и фиг с ним" редко проходит. Как минимум — нужно отправлять такие сообщения в dead letters и потом вручную разбираться.
Так обычно и происходит. Удаленные из очереди складываются в отдельный список "мертвых" сообщений.


M>Плюс есть большая проблема с N. Точнее, с интервалом между первой и последней попытками отправки сообщения. Если это меньше часа — есть хороший шанс потерять сообщения, когда ляжет инфраструктура (сеть, kubernetes, маршрутизация, что там еще любят техопсы). Ляжет cloud provider в отдельной зоне. В потребителе сообщений будет баг, при котором определенные типы сообщений не могут быть обработаны (это, кстати, классный сценарий слить много сообщений в /dev/null до того, как проблема будет обнаружена). А если интервал большой, то какая разница, сколько именно раз повторится сообщение? Опять же, в типичном скучном бизнес-приложении есть большие запасы по нагрузке. В норме (стабильный операционный режим) у вас недоставленных сообщений будет вообще 0. Поэтому банальные мониторинги на очередь повторов/количество запущенных повторов/количество повторов отдельного сообщения дадут повод расставить сигналы (alerts) и в случае срабатывания неторопясь разобраться, почему же до получателся все еще не доходит.
Поэтому во всех взрослых (корпоративных) системах задержка растет экспоненциально. От миллисекунд до часов.


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

M>>>Это очень сложно в ситуации с "зависимыми entities"
G>>Вообще без разницы честно говоря.
M>А зачем вы тогда ниже жалуетесь, что все решения — сложные?
В том решении, которое я хочу видеть не продполагается "зависимых entities". Представьте себе rabbitmq, но сообщения доставлюся REST запросами на указанные эндпоинты получателя и отправляются также REST запросами на эндпоинты очереди. Вот такое решение хочу видеть. Готовое. Без самописных велосипедов и своих протоколов.