Комментарии 19
В Spring имеется Spring Stream, предоставляющий общий API для работы как с RabbitMQ, так и с Kafka. Тем, кто реализует микросервисы рекомендую обратить внимание, очень сильно упрощает работу со Spring Boot.
Указанные сообщения сохраняются в теме, a потребители подписываются на тему для получения новых сообщений.
Пожалуйста, никогда не переводите Топик кафки, как Тема. Всё русское компьюнити, кто работает с Кафкой, использует слово Топик.
А ещё:
Не генераторы, а продьюсеры
Не потребители, а консьюмеры
Не секции, а партиции
Кажется, что эти слова лучше не переводить.
Потребитель/производитель — стандартные и логичные названия, сразу отображаются в мозг. А вот кто такой консьюмер — это гадать надо
в документации есть producer и consumer и все настройки относительно этих названий… смысл вводить новые понятия нет
Абсолютно согласен с первым комментарием. Если переводятся термины, то в скобках нужно указывать оригинальное название, а не выдуманное. Продукт и официальная документация не продполагает руссификации. Когда работаешь с инстументом, не увидишь заветных "генераторов" и "тем".
И при всей этой борьбе за чистоту русского языка оставить в статье слово «инвазивный»… )))
"producer" уже заимствовано в русский как "продюсер". "partition" традиционно в ИТ переводятся как "раздел".
Отличная статья, дающие начальное общее представление о системе, но перевод терминов очень сбивает с толку — потребитель, тема и т.п. Если добавить в скобках оригинальные названия, как они даны в документации, это сделает статью практически идеальной.
Вопрос к использующим Кафку на практике в высокопроизводительных системах.
Насколько низкой end-to-end задержки можно добиться на серийном железе, при условии что нужна гарантированная доставка? То есть ни один консьюмер не должен видеть сообщение, пока оно не реплицировано как минимум на два сервера. Допустим пропуская способность не критична (сообщения маленькие).
А то в статье много про «минимальные задержки, высокую пропускную способность, отказоустойчивость» и мало конкретных цифр. Погуглил бенчмарки — везде упоминается минимум 1 миллисекунда, что несколько больше чем надо.
Насколько низкой end-to-end задержки можно добиться на серийном железе, при условии что нужна гарантированная доставка? То есть ни один консьюмер не должен видеть сообщение, пока оно не реплицировано как минимум на два сервера. Допустим пропуская способность не критична (сообщения маленькие).
А то в статье много про «минимальные задержки, высокую пропускную способность, отказоустойчивость» и мало конкретных цифр. Погуглил бенчмарки — везде упоминается минимум 1 миллисекунда, что несколько больше чем надо.
Спасибо за комментарии по терминам, уточним варианты и учтем при литературной редактуре (как раз ею занимаемся)
Понимаю, что не SO, но просто кто-то как-то намекнул, что Kafka возможно сможет мне помочь. Допустим есть такая задача, которая сегодня решена (очень плохо решена) с помощью RabbitMq и поможет ли Kafka с ней справиться?
Есть N продюсеров, публикующих сообщения и порядок сообщений от каждого продюсера критично важен, а так же N — величина не постоянная, нужно реагировать на ее увеличение и уменьшение. Сообщения публикуются примерно раз в 4 сек, обработка занимает 2-3 сек, но иногда бывают временные сбои из-за которых обработка занимает порядка 6-20 сек.
Сегодня для каждого продюсера выделена очередь в которую он пишет и для каждой очереди есть консюмер (Kubernetes Pod) который из нее читает. Неоправданно дорогое решение, ведь каждая реплика консюмера может одновременно читать с 10, а то и больше очередей. Трудность заключается в том, что если каждому Pod'у заранее давать список очередей, которые он должен слушать, то при появлении новой очереди, невозможно назначить ее обработчиком уже существующий Pod. С другой стороны, если Pod'у динамически назначать очереди для прослушивания, то при падении, такой Pod потеряет информацию о назначенных ему очередях, а значит эти очереди «повиснут в воздухе».
Есть идея решения этой проблемы, но придется общаться с Kubernetes Api чего бы хотелось избежать.
Так вот, кто нибудь может предложить, как можно сэкономить на консюмерах, и что для этого может предложить Kafka?
Есть N продюсеров, публикующих сообщения и порядок сообщений от каждого продюсера критично важен, а так же N — величина не постоянная, нужно реагировать на ее увеличение и уменьшение. Сообщения публикуются примерно раз в 4 сек, обработка занимает 2-3 сек, но иногда бывают временные сбои из-за которых обработка занимает порядка 6-20 сек.
Сегодня для каждого продюсера выделена очередь в которую он пишет и для каждой очереди есть консюмер (Kubernetes Pod) который из нее читает. Неоправданно дорогое решение, ведь каждая реплика консюмера может одновременно читать с 10, а то и больше очередей. Трудность заключается в том, что если каждому Pod'у заранее давать список очередей, которые он должен слушать, то при появлении новой очереди, невозможно назначить ее обработчиком уже существующий Pod. С другой стороны, если Pod'у динамически назначать очереди для прослушивания, то при падении, такой Pod потеряет информацию о назначенных ему очередях, а значит эти очереди «повиснут в воздухе».
Есть идея решения этой проблемы, но придется общаться с Kubernetes Api чего бы хотелось избежать.
Так вот, кто нибудь может предложить, как можно сэкономить на консюмерах, и что для этого может предложить Kafka?
Чему равно N (хотя бы порядок)? Какие есть требования помимо «порядок сообщений от каждого продюсера критично важен»?
Кафка предоставляет мощные инструменты для работы с данными (например, Kafka Streams или KSQL). При этом, в Кафка есть гарантия на порядок сообщений внутри одной партиции. Кроме того, в Кафке поддерживаются все три варианта семантик: at-most-once, at-least-once и exactly-once.
Кафка предоставляет мощные инструменты для работы с данными (например, Kafka Streams или KSQL). При этом, в Кафка есть гарантия на порядок сообщений внутри одной партиции. Кроме того, в Кафке поддерживаются все три варианта семантик: at-most-once, at-least-once и exactly-once.
N — несколько тысяч, в перспективе — несколько десятков миллионов. Спасибо за наводку на exactly-once, вроде то что надо.
Есть еще вопрос. Можно ли с Кафка реализовать следующее?
1. Продюсеры пишут сообщение в конкретный топик и конкретную секцию
2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)
3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.
Если это возможно, то это будет идеальным решением для меня.
Спасибо.
Есть еще вопрос. Можно ли с Кафка реализовать следующее?
1. Продюсеры пишут сообщение в конкретный топик и конкретную секцию
2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)
3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.
Если это возможно, то это будет идеальным решением для меня.
Спасибо.
1. Продюсеры пишут сообщение в конкретный топик и конкретную секциюProducer может указать и конкретный топик, и конкретную партицию в нём.
// Ответ на вопрос: "да"2. Консюмеры опрашивают брокера на наличие новых сообщений в топике (без привязки к секции)Consumer может работать как в режиме publish/subscribe, т.е. сколько угодно Consumer может читать одни и те же данные, так и в режиме message queue, когда одно сообщение читается ровно одним Consumer. В последнем случае все Consumer объединяются в Consumer Group для чтения из одного топика, и одновременно из каждой партиции читает ровно один Consumer (балансировщик контролирует, если один из Consumer отпадёт, то свободный Consumer будет читать сообщения).
// Ответ на вопрос: "да"3. Брокер отдает (одновременно) неограниченное количество сообщений из топика но не больше одного сообщения из конкретной секции.Не понял смысла выделенного фрагмента. Это как-то коррелирует с моим комментарием по второму пункту относительно работы Consumer Group?
Да, какой N? Сколько консьюмеров? Какие правила назначения очередей консьюмерам?
В целом кажется что Кафка может подойти (там можно продьюсить в нужную партицию топика и т.п.), но не до конца ясны детали проблемы.
Жель из конкурентов упомянут только RabbitMQ, и то в комментариях. Неужто других конкурентов нет?..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apache Kafka: обзор