Основи надійної інтеграції через журнали подій
У червні 2016 року актуальна версія Apache Kafka 0.10.0.0 надає інструменти для створення відмовостійких інтеграційних рішень. На відміну від класичних черг, Kafka базується на розподіленому журналі, де ключову роль відіграють partitions. Порядок повідомлень гарантується лише в межах однієї партиції. Якщо для вашого бізнес-процесу — наприклад, оновлення замовлення — критична послідовність дій, обов'язково використовуйте ідентифікатор замовлення як ключ (key) при публікації. Це гарантує потрапляння всіх пов'язаних подій в одну партицію.
Керування офсетами та стратегії deduplication
Кожен споживач (consumer) у Kafka відстежує свою позицію в журналі за допомогою offset. Це дає змогу налаштовувати глибину перечитування даних у межах періоду зберігання, встановленого параметрами retention. Важливо пам'ятати, що Kafka 0.10 не підтримує транзакції для наскрізної гарантії exactly-once, тому відповідальність за deduplication лягає на прикладний рівень. Якщо ваш споживач після обробки повідомлення виходить з ладу до моменту фіксації офсету, після перезапуску повідомлення надійде знову. Рекомендуємо реалізувати ідемпотентність: перевіряйте унікальний ідентифікатор операції в цільовій системі (наприклад, ERP) перед тим, як остаточно записати зміни.
Архітектурна надійність і реплікація
Для забезпечення високої доступності налаштуйте реплікацію partitions між брокерами. З появою у версії 0.10 функції Rack Awareness, ви можете розміщувати репліки на різних фізичних стійках, що нівелює ризики збоїв живлення. Пам'ятайте, що надійність — це баланс. Використання acks=all та правильне налаштування min.insync.replicas гарантує, що жодна подія не буде втрачена, хоча це дещо знижує пропускну здатність запису. Не сприймайте Kafka як довгострокове сховище — використовуйте її для буферизації потоків, а критичні дані завжди дублюйте в авторитетних системах обліку.
Автор матеріалу