Могут ли несколько потребителей Kafka читать одно и то же сообщение из раздела

Мы планируем написать потребителя Kafka (java), который читает очередь Kafka для выполнения действия, которое находится в сообщении.

Поскольку потребители работают независимо, будет ли сообщение обрабатываться одновременно только одним потребителем? В противном случае все потребители обрабатывают одно и то же сообщение, поскольку у них есть собственное смещение в разделе.

Пожалуйста, помогите мне понять.


apache-kafka kafka-consumer-api
person shiv455    schedule 22.02.2016    source источник
comment
похоже, у кафки нет очередей. у него есть только темы   -  person gstackoverflow    schedule 29.09.2017
comment
Все темы кафки - это упорядоченные наборы, другими словами, это очереди.   -  person Rodney P. Barbati    schedule 30.03.2018
comment
Kafka topics не являются очередями, потому что после того, как сообщение потребляется из topic, оно остается там (если его время жизни не истекло), а offset перемещается к следующему, тогда как для очереди, когда сообщение потреблено, сообщение удаляется из эта очередь. Заказанные наборы также есть только на partitions.   -  person jumping_monkey    schedule 05.06.2020

Ответы (3)


arrow_upward
137
arrow_downward

Это зависит от идентификатора группы. Допустим, у вас есть тема с 12 разделами. Если у вас есть 2 потребителя Kafka с одинаковым идентификатором группы, они оба будут читать 6 разделов, то есть они будут читать разные наборы разделов = разные наборы сообщений. Если у вас есть 4 косномера Kafka с одинаковым идентификатором группы, каждый из них будет читать три разных раздела и т. Д.

Но когда вы устанавливаете другой Group Id, ситуация меняется. Если у вас есть два потребителя Kafka с разными идентификаторами группы, они будут читать все 12 разделов без какого-либо вмешательства друг в друга. Это означает, что оба потребителя будут независимо читать один и тот же набор сообщений. Если у вас есть четыре потребителя Kafka с разными идентификаторами группы, все они будут читать все разделы и т. Д.

person Lukáš Havrlant    schedule 22.02.2016
comment
на самом деле я хотел бы, чтобы только 3 потребителя ... (тот же код) работали как служба демона на машинах linux в AWS ... для опроса сообщений в очереди ... так вы имеете в виду, что мне нужно назначить один и тот же groupId всем 3, чтобы только один потребитель обрабатывает сообщение за раз ... и как другие потребители узнают, успешно ли обработано сообщение, чтобы они не забрали его для обработки ... - person shiv455; 22.02.2016
comment
Вы не можете сообщить другим потребителям, что одно сообщение было обработано неправильно. Но если один потребитель терпит неудачу, другой потребитель соглашается на его работу. Значение: если у вас есть 12 разделов и 3 потребителя с одинаковым идентификатором группы, каждый потребитель читает 4 раздела. Если один потребитель терпит неудачу, происходит ребалансировка, и теперь два живых потребителя прочитал 6 разделов. Имейте в виду, что если вы не обновляете смещение после каждого сообщения, вы можете прочитать некоторые сообщения более одного раза. - person Lukáš Havrlant; 22.02.2016
comment
извините, я думаю, мой вопрос сбивает с толку ... позвольте мне разбить его 1. если сообщение обрабатывается потребителем и смещение зафиксировано. теперь во время обработки сообщения внешние зависимости потребителя не работают и сообщение не обработано, потребитель работает и работает, хотя ... как сообщение будет повторяться, поскольку смещение установлено для чтения следующего сообщения потребителем ... 2, если потребитель обрабатывает сообщения в определенном разделе, и он может обрабатывать несколько сообщений и умер, вы сказали произойдет ребалансировка, и разделы будут перераспределены, как другие потребители узнают смещение умершего потребителя - person shiv455; 22.02.2016
comment
1) Вы можете использовать низкоуровневый потребительский API (или в новом Kafka 0.9 есть совершенно новый потребительский API, я его еще не читал), это дает вам возможность самостоятельно управлять фиксацией смещения. Это означает, что вы можете дождаться окончательной обработки сообщения и после этого сохранить смещение. Нет простого способа обработать уже обработанное и зафиксированное сообщение. Я думаю, что в этом случае вам нужно запустить нового потребителя и сказать ему, чтобы он снова потреблял сообщение со смещением XYZ или что-то в этом роде. - person Lukáš Havrlant; 22.02.2016
comment
2) Смещение определяется идентификатором темы, раздела и группы. Живые потребители с одним и тем же идентификатором группы могут получить смещение, потому что они читают одну и ту же тему и имеют одинаковый идентификатор группы. - person Lukáš Havrlant; 22.02.2016
comment
Спасибо @Lukas Havrlant .... у нас есть java restapi, который должен работать как производитель для записи в очередь ... нужно ли производителю знать, какой раздел ему нужен для записи сообщения ??? пожалуйста, предложите образец, с которого я могу начать, и включить логику производителя в мой Rest api ... - person shiv455; 22.02.2016
comment
И для 1) я предполагаю, что если внешние зависимости терпят неудачу, не фиксируйте смещение, чтобы оно повторило попытку обработки сообщения .. это звучит как обходной путь? - person shiv455; 22.02.2016
comment
Позвольте нам продолжить это обсуждение в чате. - person shiv455; 23.02.2016
comment
зачем два раза потреблять одно и то же сообщение двумя разными потребителями? - person Faiz Halde; 26.08.2016
comment
@FaizHalde: В нашем случае: сначала мы потребляем каждое сообщение для обработки в реальном времени, а позже мы потребляем тот же набор сообщений во второй раз, когда мы передаем сообщение из Kafka в HDFS для дальнейшего анализа. В общем, если у вас несколько микросервисов, каждый из них может читать одни и те же сообщения и делать с ними разные вещи. - person Lukáš Havrlant; 26.03.2017
comment
Что происходит, когда в одной группе больше потребителей, скажем, 14 и только 12 разделов? Могут ли резервные потребители по-прежнему подключаться к Kafka? - person Bianca Tesila; 23.08.2018
comment
@BiancaTesila Два оставшихся потребителя будут подключены, но они ничего не читают. В основном они были бы неактивными. - person Lukáš Havrlant; 24.08.2018
comment
@ LukášHavrlant, не будет ли проблема запутана из-за смещения одной группы потребителей на другую? Если потребительская группа завершит обработку, она создаст смещение. Но если обработка другой группы потребителей не выполняется .. Будут ли доступны те же данные в теме для другой группы потребителей - person OK999; 27.03.2019
comment
Что, если потребителей в одной группе потребителей больше, чем количество разделов? Тогда несколько потребителей могут в конечном итоге читать из одного раздела, верно? Разве это не вызовет нежелательных побочных эффектов, таких как обработка одних и тех же данных дважды? - person AV94; 11.04.2019
comment
что, если в теме есть один раздел, но несколько потребителей в одной группе, как это будет работать? - person lollerskates; 22.07.2021

arrow_upward
22
arrow_downward

Я нашел это изображение от OReilly полезным:

kafka

В той же группе: НЕТ

  • Два потребителя (Потребитель 1, 2) в одной группе (Группа 1) НЕ МОГУТ получать одно и то же сообщение из раздела (Раздел 0).

В разных группах: ДА

  • Два потребителя в двух группах (Потребитель 1 из Группы 1, Потребитель 1 из Группы 2) CAN получают то же сообщение из раздела (Раздел 0).
person SynergyChen    schedule 06.11.2020

arrow_upward
16
arrow_downward

Kafka доставляет каждое сообщение в темах, на которые вы подписаны, одному процессу в каждой группе потребителей. Это достигается за счет балансировки разделов между всеми членами в группе потребителей, так что каждый раздел назначается ровно одному потребителю в группе. Концептуально вы можете думать о группе потребителей как о едином логическом подписчике, который состоит из нескольких процессов.

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

person Karan Khanna    schedule 26.12.2018
comment
Большое тебе спасибо. Это помогло мне понять настоящую цель группы потребителей. - person Somebody; 19.11.2020