Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 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 и более подписчиков, когда сначала архитектура предполагала одного получателя, а потом вдруг нарисовались ещё, а последовательно отсылать по цепочке не вариант.

Ну и ещё нужно помнить про то, что если заранее в кролике не позаботиться о персистентности хранения события сначала на диске, то развал кластера с потерей всех событий что были в тот момент в памяти невычитанными при потере сетевой коннективности с необходимостью пересоздания кластера это прям реальность, о которой почему-то многие умалчивают.

Плюс нюансы с отдельными ретрай очередями на повтор, когда нарушается порядок вычитывания событий при восстановлении подписчика после сбоя.

Я к тому, что любую систему нужно уметь хорошо готовить под целевое использование, и не всегда эта цель видится в самом начале отчётливо )

Ну, например, есть 100500 адресов, которые нужно провалидировать. Есть кластер из 10 машин, которым нужно очень быстро разбросать адреса, без повторения. Можно и через Rabbit, но если уже есть Кафка, то почему не использовать её, чтобы не плодить инфраструктуру.

Вот ключевые особенности Kafka, полезные для микросервисов:

Прям отчётливо пахнуло ИИ! А зукипер уже давно не используется. Честно говоря надеялся, что эта команда сама пишит статьи. Разочарован.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий