У сучасній архітектурі, де ERP-система працює паралельно з мікросервісами, критично важливо передавати повідомлення про бізнесові події, такі як підтвердження замовлення. Проблема виникає, коли застосунок має оновити запис у БД і надіслати подію до Apache Kafka. Якщо одна з цих дій завершиться помилкою, системи втратять синхронізацію. Шаблон Transactional Outbox вирішує це, записуючи бізнесову зміну та подію в одній транзакції.
Практична реалізація з Debezium 0.9.5
Для забезпечення атомарності ми створюємо таблицю outbox_events у тій же базі, де зберігаються бізнесові дані. Завдяки Debezium 0.9.5.Final (випущеному 6 травня 2019 року), ми використовуємо функцію CDC (Change Data Capture) для моніторингу цієї таблиці. Використання Debezium 0.9.3+ разом з Outbox SMT дозволяє автоматично трансформувати технічні записи БД у бізнесові повідомлення для Kafka.
Уявімо приклад: замовлення ORD-2019-5824 змінює статус на 'CONFIRMED'. Транзакція СУБД одночасно оновлює таблицю замовлень та додає запис до outbox_events. Debezium фіксує цю подію через лог транзакцій і передає її в Kafka без додаткових розподілених транзакцій.
Важливість ідемпотентності
Хоча Outbox гарантує, що подія буде записана, вона може бути доставлена до споживача кілька разів через мережеві збої. Тому споживач (consumer) має бути ідемпотентним. Використання event_id з таблиці outbox дозволяє споживачу перевірити, чи була подія вже опрацьована, звертаючись до таблиці processed_events у своїй базі даних перед виконанням дій. Це ключовий елемент надійності, що дозволяє уникнути повторного опрацювання бізнесових операцій.
Порядок подій та Data Warehouse
Для аналітичних систем, таких як корпоративний Data Warehouse, важливо отримувати події в правильному порядку. Використання aggregate_id як ключа повідомлення Kafka гарантує, що всі події одного об'єкта потрапляють до однієї партиції. Це дозволяє уникнути конфліктів та забезпечити коректність аналітичних показників, спираючись на надійний ланцюг передачі даних від ERP до кінцевих систем.
Автор матеріалу