Comments 10
Kafka распределяет сообщения, позволяя нескольким экземплярам обрабатывать события одновременно.
Разве для этого не нужно разбивать топик на партиции? И скейлинг может быть затруднен необходимостью делать repartition, если не угадал с их изначальным количеством и текущие консьюмеры не справляются с напором
Я бы рекомендовал внимательно посмотреть в сторону https://github.com/confluentinc/parallel-consumer - во многих обстоятельствах, это позволяет оставить партиции девопсам для резервинования/надежности/etc - а параллелизм внутри консьюмера регулировать чисто программно на клиентской стороне. Разумеется, на практике - скорее применяется схема MxN, где - M - количество партиций, а N - параллелизм внутри консьюмера. Это позволяет в более широких пределах адаптироваться к нагрузке без пересоздания топиков...
Pub-sub это здорово, но что делать, если событие должно обрабатываться только один раз, а нод в кластере много. Как Кафка работает с очередями?
Принципиальная гарантия кафки - "at least once". И я не знаю систем, которые бы гарантировали из коробки exactly once. В некоторых краевых условиях будет либо at least once, либо at most once. Дополнительные гарантии делайте на клиентской стороне: либо идемпотентность, либо трекайте прогресс обработки в БД чтобы отсеивать дубликаты...
JMS (Artemis, RabbitMQ, etc.) предоставляет очереди из которых читают подписчики и каждое сообщение обрабатывается только одним подписчиком.
Слабо представляю себе систему, где нужно, чтобы бизнес событие вычитывалось рандомно разными сервисами 1 раз. Всё остальное реализуется в amqp типа кролика как отправление конкретного типа события для конкретного подписчика, и там наоборот нужно поприседать чтобы отправить 1 событие на 2 и более подписчиков, когда сначала архитектура предполагала одного получателя, а потом вдруг нарисовались ещё, а последовательно отсылать по цепочке не вариант.
Ну и ещё нужно помнить про то, что если заранее в кролике не позаботиться о персистентности хранения события сначала на диске, то развал кластера с потерей всех событий что были в тот момент в памяти невычитанными при потере сетевой коннективности с необходимостью пересоздания кластера это прям реальность, о которой почему-то многие умалчивают.
Плюс нюансы с отдельными ретрай очередями на повтор, когда нарушается порядок вычитывания событий при восстановлении подписчика после сбоя.
Я к тому, что любую систему нужно уметь хорошо готовить под целевое использование, и не всегда эта цель видится в самом начале отчётливо )
Вот ключевые особенности Kafka, полезные для микросервисов:
Прям отчётливо пахнуло ИИ! А зукипер уже давно не используется. Честно говоря надеялся, что эта команда сама пишит статьи. Разочарован.
Event-driven микросервисы с использованием Spring Boot и Kafka