Ещё одна статья нытья человека, который не осилил простую концепцию. Доводы высосаны из пальца, что что-то непонятно. Люди кучу книг написали, но автору всё ещё непонятно.
Многие языки нынче мультипарадигменные, чистые ООП уже не используются. Поэтому вопрос - пишите как хотите на любом современном языке, проблем не вижу.
Уровень изоляции 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 - не зря его называют самым сложным и редко реализуют.
Ещё одна статья нытья человека, который не осилил простую концепцию. Доводы высосаны из пальца, что что-то непонятно. Люди кучу книг написали, но автору всё ещё непонятно.
Многие языки нынче мультипарадигменные, чистые ООП уже не используются. Поэтому вопрос - пишите как хотите на любом современном языке, проблем не вижу.
Менеджеры настолько менеджат, что людям работать некогда. Код то когда писать?
"Дед опять забыл таблетки выпить"
Попробуйте идти в ногу со временем, истина где-то посередине.
попытка создать новый кубер?
Ссылка на диаграмму не работает, а на картинке ничего не видно
Не советую связываться с 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 - не зря его называют самым сложным и редко реализуют.