Comments 10
Задача с крепостью имеет название: "Проблема византийских генералов", интересная тема
Есть задача двух генералов и есть задача византийских генералов. Они немного отличаются. Первая скорее про ненадежность связи. Вторая скорее про консенсус, насколько я понимаю
Все думал, пока читал, когда появятся секреты 100% доставки на примере какого-нибудь брокера... Может Кафки...
Спасибо, полезный материал, про нестабильность сети часто забывают) про Transactional Outbox интересно будет почитать
Жду вторую часть)
Вы немного перемешали все понятия в одну кучу, как мне кажется.
В заголовке есть слово "брокер", но где в вашей схеме сам брокер? Server - явно выглядит как приложение с логикой, потому что выполняет умную логику по обработке сообщений.
Само понятие - Exactly-one delivery часто применяется к сообщениям, можно ли назвать сетевой вызов сообщением? я бы не сказал.
При отправке сообщения у нас обычно есть паттерн - Publisher - Subscriber и промежуточный брокер - который получает и отдаёт сообщение. И тут то и начинается 3 типа гарантии как мне кажется с каждой стороны.
То, что вы показываете в статье, относится к отправке сообщения, и получение его брокером. Для этого как раз чаще и используется Outbox Pattern, но точно такие же 3 типа гарантий есть при получении сообщения cosumer'ом, и там уже другие способы применяются.
Рассмотренный способ с Idempotancy в статье называется Application level exactly once. Но он так же может быть и на уровне Broker и на уровне Application Framework. Например - 'Умный' consumer может посылать последний считанный номер сообщения в последовательности брокеру и брать сообщение, которое ещё не успел обработать. Это не совсем Idempotancy, механизм по-другому работает.
Чем больше и сложнее система - тем сложнее реализовать Exactly once - не зря его называют самым сложным и редко реализуют.
Вы немного перемешали все понятия в одну кучу, как мне кажется.
Возможно. Но это, пожалуй, именно что размышления, основанные на разных источниках. Хотелось создать некий мысленный фреймворк, чтобы было удобно мыслить понятиями. Может быть, это получилось и не очень.
В заголовке есть слово "брокер", но где в вашей схеме сам брокер? Server явно выглядит как приложение с логикой, потому что выполняет умную логику по обработке сообщений.
Все верно, сам брокер не упоминается. Это первая часть, которая должна "подвести" читателя и дать легкий фреймворк для мышления в терминах гарантий доставки, чтобы было понятно, что имеется в виду по аналогии простого веб приложения. Брокер считай тот же самый сервер. Задумка была как-то это рассказать в серии статей.
Само понятие - Exactly-one delivery часто применяется к сообщениям, можно ли назвать сетевой вызов сообщением? я бы не сказал.
А почему нет? Сетевой вызов под капотом это отправка того же самого сообщения
При отправке сообщения у нас обычно есть паттерн - Publisher -
Subscriber и промежуточный брокер - который получает и отдаёт сообщение.
И тут то и начинается 3 типа гарантии как мне кажется с каждой стороны.
Да-да, все верно. Была задумка во второй статье рассказать про гарантии доставки со стороны продьюсера и про transactional outbox. В третьей статье рассказать про гарантии обработки со стороны консьюминга(показать, что меняя место commit/ack меняется и гарантия обработки).
Рассмотренный способ с Idempotancy в статье называется Application level
exactly once. Но он так же может быть и на уровне Broker и на уровне
Application Framework. Например - 'Умный' consumer может посылать
последний считанный номер сообщения в последовательности брокеру и брать
сообщение, которое ещё не успел обработать. Это не совсем Idempotancy,
механизм по-другому работает.
Спасибо, не знал об этом
Разбираемся с работой брокеров, или Что такое гарантия доставки сообщений и как с этим жить…