Outbox и двойная запись
Вопрос
Почему нельзя просто записать в базу и потом отправить событие в Kafka, и как это решается?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Две записи не атомарны: падение между ними даёт рассинхрон
Отправка до записи даёт обратную проблему
Outbox: событие в таблицу той же транзакцией
Публикация из outbox поллером или CDC
At-least-once и идемпотентные потребители
Очистка outbox и порядок событий по ключу
Что могут спросить следом
- Чем поллер хуже CDC для outbox?
- Как потребитель отличит повтор?
Разбор
Образцовый ответ: «База и Kafka это две независимые системы, и записать в обе атомарно без распределённой транзакции нельзя. Если процесс упадёт после коммита в базу, событие потеряется; если отправить событие первым, а транзакция откатится, потребители узнают о несуществующем заказе. Outbox решает это: в той же транзакции, что и заказ, сервис пишет запись в таблицу outbox. Отдельный процесс читает outbox и публикует в Kafka: поллер по таблице или CDC, например Debezium с роутером outbox-событий. Доставка получается at-least-once, поэтому у события есть id, и потребители дедуплицируют. Ключ сообщения выбираю по сущности, чтобы события одного заказа шли по порядку. Обработанные записи outbox периодически чищу. CDC лучше поллера: меньше задержка и нет нагрузки частыми запросами».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Предыдущий вопрос
Способы инкрементальной загрузки
Следующий вопрос
Применить пачку CDC-событий к таблице
Ещё по теме «CDC и инкрементальная загрузка»
- Удаления в аналитике
- Событие Debezium
- Transactional outbox
- Инкремент по водяному знаку
- Применить события Debezium к состоянию
- Поле op в событии Debezium
- Удаления при инкременте по updated_at
- Спроектируйте репликацию данных сервисов в хранилище через CDC