Прекрасно, разносторонний опыт. Но давай-те посмотрим на вопрос с другой стороны. Вы пишите, что существуют 3 вида доставки, и это очень важное слово, потому что в интернете уже давно разделили понятие доставки и обработки. То, что вы говорите - это есть обработка сообщения, и она может быть Exactly-once с разными подходами, где за счёт логики consumer это всё делается.
Но само понятие Message Delivery - это свойство брокеров, где:
at-most-once - если сейчас нет consumer сообщение теряется
at-least-once - consumer забрал, но не удалю, пока не получу confirm
exactly-once - кто-то забрал один раз, но не подтвердил, отправлю сообщение DLQ, пусть кто-то сам разберётся.
Поэтому Exactly-once delivery никто не делал, потому что сложно реализовать и постоянно нужно что бы человек смотрел из DLQ, а что там приключилось.
Поэтому люди решили, что будем называть Exactly-once processing, где уже разными способами, которые и вы перечислили учитывается обработка мессаджи со всеми side-effects.
Наводящий вопрос - видели ли вы систему, где будет At-least-once processing, и обработка мессаджа будет идемпотента?
Вы неправильно понимаете что такое exactly once. В банковских платежах используется at least once. И для этой гарантии как раз и применяется проверка на уровне логики, или unique id платежа.
Чтобы лучше пояснить - приведите реализацию банковской транзакции двумя способами - at least once и exactly once. А я попробую увидеть разницу
Ещё одна статья нытья человека, который не осилил простую концепцию. Доводы высосаны из пальца, что что-то непонятно. Люди кучу книг написали, но автору всё ещё непонятно.
Многие языки нынче мультипарадигменные, чистые ООП уже не используются. Поэтому вопрос - пишите как хотите на любом современном языке, проблем не вижу.
Уровень изоляции READ UNCOMMITTED в PostgreSQL не отличается от READ COMMITTED. Другими словами - грязное чтение невозможно. Это написано в документации
PostgreSQL's Read Uncommitted mode behaves like Read Committed.
не знаю почему минусуют, возможно из-за оформления кода. Но идея правильная. Так же сделано в в библиотеке Polly - инфраструктурный код вынесен и разделен с бизнес логикой, всё прекрасно, все довольны.
Вы немного перемешали все понятия в одну кучу, как мне кажется.
В заголовке есть слово "брокер", но где в вашей схеме сам брокер? Server - явно выглядит как приложение с логикой, потому что выполняет умную логику по обработке сообщений.
Само понятие - Exactly-one delivery часто применяется к сообщениям, можно ли назвать сетевой вызов сообщением? я бы не сказал.
При отправке сообщения у нас обычно есть паттерн - Publisher - Subscriber и промежуточный брокер - который получает и отдаёт сообщение. И тут то и начинается 3 типа гарантии как мне кажется с каждой стороны.
То, что вы показываете в статье, относится к отправке сообщения, и получение его брокером. Для этого как раз чаще и используется Outbox Pattern, но точно такие же 3 типа гарантий есть при получении сообщения cosumer'ом, и там уже другие способы применяются.
Рассмотренный способ с Idempotancy в статье называется Application level exactly once. Но он так же может быть и на уровне Broker и на уровне Application Framework. Например - 'Умный' consumer может посылать последний считанный номер сообщения в последовательности брокеру и брать сообщение, которое ещё не успел обработать. Это не совсем Idempotancy, механизм по-другому работает.
Чем больше и сложнее система - тем сложнее реализовать Exactly once - не зря его называют самым сложным и редко реализуют.
Прекрасно, разносторонний опыт. Но давай-те посмотрим на вопрос с другой стороны. Вы пишите, что существуют 3 вида доставки, и это очень важное слово, потому что в интернете уже давно разделили понятие доставки и обработки. То, что вы говорите - это есть обработка сообщения, и она может быть Exactly-once с разными подходами, где за счёт логики consumer это всё делается.
Но само понятие Message Delivery - это свойство брокеров, где:
at-most-once - если сейчас нет consumer сообщение теряется
at-least-once - consumer забрал, но не удалю, пока не получу confirm
exactly-once - кто-то забрал один раз, но не подтвердил, отправлю сообщение DLQ, пусть кто-то сам разберётся.
Поэтому Exactly-once delivery никто не делал, потому что сложно реализовать и постоянно нужно что бы человек смотрел из DLQ, а что там приключилось.
Поэтому люди решили, что будем называть Exactly-once processing, где уже разными способами, которые и вы перечислили учитывается обработка мессаджи со всеми side-effects.
Наводящий вопрос - видели ли вы систему, где будет At-least-once processing, и обработка мессаджа будет идемпотента?
Вы неправильно понимаете что такое exactly once. В банковских платежах используется at least once. И для этой гарантии как раз и применяется проверка на уровне логики, или unique id платежа.
Чтобы лучше пояснить - приведите реализацию банковской транзакции двумя способами - at least once и exactly once. А я попробую увидеть разницу
Ещё одна статья нытья человека, который не осилил простую концепцию. Доводы высосаны из пальца, что что-то непонятно. Люди кучу книг написали, но автору всё ещё непонятно.
Многие языки нынче мультипарадигменные, чистые ООП уже не используются. Поэтому вопрос - пишите как хотите на любом современном языке, проблем не вижу.
Менеджеры настолько менеджат, что людям работать некогда. Код то когда писать?
"Дед опять забыл таблетки выпить"
Попробуйте идти в ногу со временем, истина где-то посередине.
попытка создать новый кубер?
Ссылка на диаграмму не работает, а на картинке ничего не видно
Не советую связываться с Debezium
Статья уровня Beginner Tutorial, а где среднего уровня контент?
Уровень изоляции READ UNCOMMITTED в PostgreSQL не отличается от READ COMMITTED. Другими словами - грязное чтение невозможно. Это написано в документации
молодцы, очень актуально и свежо!
не знаю почему минусуют, возможно из-за оформления кода.
Но идея правильная. Так же сделано в в библиотеке Polly - инфраструктурный код вынесен и разделен с бизнес логикой, всё прекрасно, все довольны.
Думаю автор просто неудачно слова подобрал.
Вы немного перемешали все понятия в одну кучу, как мне кажется.
В заголовке есть слово "брокер", но где в вашей схеме сам брокер? Server - явно выглядит как приложение с логикой, потому что выполняет умную логику по обработке сообщений.
Само понятие - Exactly-one delivery часто применяется к сообщениям, можно ли назвать сетевой вызов сообщением? я бы не сказал.
При отправке сообщения у нас обычно есть паттерн - Publisher - Subscriber и промежуточный брокер - который получает и отдаёт сообщение. И тут то и начинается 3 типа гарантии как мне кажется с каждой стороны.
То, что вы показываете в статье, относится к отправке сообщения, и получение его брокером. Для этого как раз чаще и используется Outbox Pattern, но точно такие же 3 типа гарантий есть при получении сообщения cosumer'ом, и там уже другие способы применяются.
Рассмотренный способ с Idempotancy в статье называется Application level exactly once. Но он так же может быть и на уровне Broker и на уровне Application Framework. Например - 'Умный' consumer может посылать последний считанный номер сообщения в последовательности брокеру и брать сообщение, которое ещё не успел обработать. Это не совсем Idempotancy, механизм по-другому работает.
Чем больше и сложнее система - тем сложнее реализовать Exactly once - не зря его называют самым сложным и редко реализуют.