Kafka и Transactional Outbox. Есть ли альтернативы? / Сергей Попов (Синимекс)
Вставка
- Опубліковано 2 чер 2024
- Есть стандартная задача: сохранять изменения в БД и отправлять об этом сообщение в Кафку. Причём хочется, чтобы было честно: успешно отправили и успешно сохранили, либо же - ничего не отправили и ничего не сохранили.
Во всех учебниках предлагают использовать паттерн Transactional Outbox. Но так ли он хорош? Есть ли альтернативы? И что лучше?
Обо всём этом рассказал Сергей Попов, Tech Expert IT-компании "Cinimex"
Таймкоды:
00:00 - Начало
00:49 - Перейдем к задачке. Какая есть проблема?
02:32 - Решение проблем. Transactional outbox + Polling Publisher и...
06:36 - Какие еще есть варианты? Kafka Transactional из spring-kafka, семантики в kafka?
10:52 - Синхронный REST. Какие минусы?
12:37 - Одна база и Kafka - источник правды?
15:10 - Что же использовать? Зависит от...
17:24 - Вопросы к спикеру
Habr: habr.com/ru/companies/cinimex...
Наша жизнь и новости в Telegram: t.me/cinimex
Наш сайт: www.cinimex.ru/career/
Я так и не понял, зачем пытаться избавиться от дублей на Продюсере, если Консъюмер всё равно должен быть идемпотентным (а он должен быть, т.к. из-за сетевых ошибок и падений приложения Консъюмера возможны повторные доставки - acknowledgement получения сообщения может быть не послан или не дойти до брокера Кафки).
Интересна идея "mirrored outbox pattern", которая родилась при просмотре этого видео (когда сообщение сначала отправляется в Кафку, а затем Консъюмер этого же приложения читает Кафку и пишет из неё в свою БД).
Ответ на вопрос "зачем?" - перфекционизм. 30-40 лет назад такие задачи имели простое (хоть и низкопроизводительное - хотя стоило бы произвести замер на современном оборудовании) решение, а сейчас?! Ресурсов в разы больше, а мы их бездарно (на мой взгляд, конечно) тратим на хранение дублей и дедупликацию на каждом сервисе...
По поводу "mirrored outbox pattern". Консьюмер естественно должен быть индепотентен и да, будет работать.
UPD для интересующихся: обнаружил, что для названного мною "mirrored outbox pattern" есть общепринятое название - Listen to Yourself pattern
Не тратьте свое время, доклад пустой, решения проблемы нет, в минусы докладчик записывает At-Least-Once семантику, что говорит об уровне подготовки докладчика. 10 лет опыта - плохой показатель, каждый может потратить этот срок с разной степенью эффективности
Спасибо за мнение. Но я всё равно буду стоять на том, что at-least-once лишь маскирует проблему, а не решает. А решения в докладе всё же были. Только у каждого свои плюсы и минусы.
@TransactionalEventListener
А если сразу после коммита в БД приложение ляжет? Или случится сбой при отправке сообщения в Кафку? In-memory ненадёжно.
Как заметил предыдущий комментатор, также могут возникать проблемы. И transactional outbox выглядит надёжней.