Не тратьте свое время, доклад пустой, решения проблемы нет, в минусы докладчик записывает At-Least-Once семантику, что говорит об уровне подготовки докладчика. 10 лет опыта - плохой показатель, каждый может потратить этот срок с разной степенью эффективности
Спасибо за мнение. Но я всё равно буду стоять на том, что at-least-once лишь маскирует проблему, а не решает. А решения в докладе всё же были. Только у каждого свои плюсы и минусы.
Я так и не понял, зачем пытаться избавиться от дублей на Продюсере, если Консъюмер всё равно должен быть идемпотентным (а он должен быть, т.к. из-за сетевых ошибок и падений приложения Консъюмера возможны повторные доставки - acknowledgement получения сообщения может быть не послан или не дойти до брокера Кафки). Интересна идея "mirrored outbox pattern", которая родилась при просмотре этого видео (когда сообщение сначала отправляется в Кафку, а затем Консъюмер этого же приложения читает Кафку и пишет из неё в свою БД).
Ответ на вопрос "зачем?" - перфекционизм. 30-40 лет назад такие задачи имели простое (хоть и низкопроизводительное - хотя стоило бы произвести замер на современном оборудовании) решение, а сейчас?! Ресурсов в разы больше, а мы их бездарно (на мой взгляд, конечно) тратим на хранение дублей и дедупликацию на каждом сервисе... По поводу "mirrored outbox pattern". Консьюмер естественно должен быть индепотентен и да, будет работать.
Спасибо за ёмкую лекцию. Хотел предложить одно решение, которое я нашёл на просторах интернета, называется "listen to yourself pattern"
Не тратьте свое время, доклад пустой, решения проблемы нет, в минусы докладчик записывает At-Least-Once семантику, что говорит об уровне подготовки докладчика. 10 лет опыта - плохой показатель, каждый может потратить этот срок с разной степенью эффективности
Спасибо за мнение. Но я всё равно буду стоять на том, что at-least-once лишь маскирует проблему, а не решает. А решения в докладе всё же были. Только у каждого свои плюсы и минусы.
Я так и не понял, зачем пытаться избавиться от дублей на Продюсере, если Консъюмер всё равно должен быть идемпотентным (а он должен быть, т.к. из-за сетевых ошибок и падений приложения Консъюмера возможны повторные доставки - acknowledgement получения сообщения может быть не послан или не дойти до брокера Кафки).
Интересна идея "mirrored outbox pattern", которая родилась при просмотре этого видео (когда сообщение сначала отправляется в Кафку, а затем Консъюмер этого же приложения читает Кафку и пишет из неё в свою БД).
Ответ на вопрос "зачем?" - перфекционизм. 30-40 лет назад такие задачи имели простое (хоть и низкопроизводительное - хотя стоило бы произвести замер на современном оборудовании) решение, а сейчас?! Ресурсов в разы больше, а мы их бездарно (на мой взгляд, конечно) тратим на хранение дублей и дедупликацию на каждом сервисе...
По поводу "mirrored outbox pattern". Консьюмер естественно должен быть индепотентен и да, будет работать.
UPD для интересующихся: обнаружил, что для названного мною "mirrored outbox pattern" есть общепринятое название - Listen to Yourself pattern
@TransactionalEventListener
А если сразу после коммита в БД приложение ляжет? Или случится сбой при отправке сообщения в Кафку? In-memory ненадёжно.
Как заметил предыдущий комментатор, также могут возникать проблемы. И transactional outbox выглядит надёжней.