Comments 5
Ряд мелких нерешенных вопросов? :) Если бы…
По-моему тут наблюдается минимум одна крупная проблема, которую вы обошли вниманием — как только используется такое решение для «гарантированной» доставки, как правило сразу становится невозможным сохранение порядка сообщений — потому что первое сообщение застряло на втором REST сервисе, а второе например прошло успешно — потому что сервис уже починили.
Неуправляемая повторная отправка только усугубляет данную проблему.
По-моему тут наблюдается минимум одна крупная проблема, которую вы обошли вниманием — как только используется такое решение для «гарантированной» доставки, как правило сразу становится невозможным сохранение порядка сообщений — потому что первое сообщение застряло на втором REST сервисе, а второе например прошло успешно — потому что сервис уже починили.
Неуправляемая повторная отправка только усугубляет данную проблему.
Рано или поздно такая транзакция будет найдена и откачена.
Блокчейн поможет :D (за счет того, что высокая вычислительная стоимость обеспечивает неплохое количество возможностей транзакции «прийти в себя»).
Если исходные данные, которые доставляются, являются немутабельными, фиксированными в каком-то промежутке — достаточно слать их с историей версий и как-то синхронизировать между получателями. Дорого, да. Но на практике вполне юзабельно.
Блокчейн поможет :D (за счет того, что высокая вычислительная стоимость обеспечивает неплохое количество возможностей транзакции «прийти в себя»).
Если исходные данные, которые доставляются, являются немутабельными, фиксированными в каком-то промежутке — достаточно слать их с историей версий и как-то синхронизировать между получателями. Дорого, да. Но на практике вполне юзабельно.
Так и не понял, в чем инновационность этого решения, или чем оно лучше ActiveMQ, RabbitMQ или IBM WebSphere MQ?
Оговоримся, что Rabbit MQ у себя в production мы не используем из-за невозможности его работы с XA.
Вместе с тем вы используете Rest, который вообще как бы не транзакционный. Странная мотивация.
Данное решение так же устраняет проблему невозможности отката транзакции при работе с внешними сервисами. Никакой вызов не пройдет дважды — обработка начинается именно с того шага, на котором произошел сбой.
Вопрос на засыпку: что делать, если мой любимый http вернул timeout? Rest обработал изменения или нет?
В вашей схеме каждый Rest-сервис должен локально записывать транзакции и автоматически игнорировать их при повторном вызове.
Как вы решаете проблему с остановкой si компонент(может быть service bus message)? почему не используете replay-channel? и на закуску почему все не обернули в chain?
Sign up to leave a comment.
Реализация гарантированной асинхронной доставки сообщений