30 lines
3.9 KiB
Markdown
30 lines
3.9 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
tags:
|
|||
|
|
- maturity/🌱
|
|||
|
|
date: 2024-11-15
|
|||
|
|
---
|
|||
|
|
Отправка сообщений в [[00 Kafka|Kafka]] из [[Транзакция БД|транзакций базы данных]] приводит к проблемам с согласованностью данных между системами, особенно в условиях распределённых систем. Если сначала происходит отправка сообщения в Kafka, а затем транзакция в БД откатывается, то сообщение останется в Kafka, но база данных не зафиксирует изменений, что приведёт к рассинхронизации данных.
|
|||
|
|
|
|||
|
|
Для обеспечения согласованности данных между базой данных и Kafka необходимо использовать следующие подходы:
|
|||
|
|
|
|||
|
|
- [[Transactional Outbox|Transactional Outbox]]. Этот подход позволяет отделить запись в базу данных от отправки сообщения в брокер. Изменения сначала фиксируются в основной таблице базы данных, а затем записываются в специальную таблицу "Outbox". Отдельный процесс или сервис асинхронно считывает из таблицы "Outbox" и отправляет сообщения в Kafka, что гарантирует согласованность данных.
|
|||
|
|
- Change Data Capture (CDC). Использование CDC с инструментами вроде Debezium позволяет отслеживать изменения в базе данных и публиковать их в Kafka. Это решение подходит для случаев, когда необходимо обеспечить автоматическую синхронизацию изменений, но может потребовать дополнительных настроек и ресурсов.
|
|||
|
|
- Распределённые транзакции (двухфазный коммит). Этот метод позволяет гарантировать согласованность между базой данных и Kafka за счёт координации транзакций между ними. Однако этот подход часто считается сложным и менее масштабируемым, особенно в распределённых системах.
|
|||
|
|
|
|||
|
|
Другая серьёзная проблема связана с возможностью двойной обработки. В случае сбоя приложения или инфраструктуры транзакции могут повторяться, приводя к дублированию событий в Kafka. Дублирование событий может вызвать некорректное состояние системы, повторное выполнение операций. Чтобы предотвратить дублирование, можно использовать следующие подходы:
|
|||
|
|
- [[highload/Идемпотентность на базе уникального идентификатора|Идемпотентность на базе уникального идентификатора]]
|
|||
|
|
***
|
|||
|
|
## Мета информация
|
|||
|
|
**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
|
|||
|
|
**Родитель**::
|
|||
|
|
**Источник**::
|
|||
|
|
**Создана**:: [[2024-11-15]]
|
|||
|
|
**Автор**::
|
|||
|
|
### Дополнительные материалы
|
|||
|
|
-
|
|||
|
|
|
|||
|
|
### Дочерние заметки
|
|||
|
|
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
|
|||
|
|
|