2016-12-06 3 views
0

Как обеспечивается упорядочение заказов при балансировке товара. Предположим, что изначально у нас есть четыре раздела: p1, p2, p3, p4 и два пользователя c1 и c2 (в той же группе). Таким образом, каждый потребитель получает два раздела, например, c1: p1, p2 и c2: p3, p4.Предоставление Kafka сообщений при балансировании потребителей

Теперь добавляются новые потребители c3 и c4, происходит перебалансировка, так что каждый потребитель получает один раздел, например c1: p1, c2: p2, c3: p3, c4: p4.

В течение этого времени существует вероятность того, что потребитель c1 может быть обработка сообщения от раздела p2 (до восстановления равновесия)

и потребитель c2 также начинают обработку p2 сообщений (после восстановления равновесия)

Даже если это угол Это ожидаемое поведение упорядочения сообщений?

+0

вы можете быть немного более ясным относительно того, что речь идет о сообщении заказ? – yaswanth

+1

Обработка сообщений может быть из других во время перебалансировки. – ravthiru

ответ

2

В течение этого времени существует вероятность того, что потребитель c1 может быть обработка сообщения от раздела p2 (до восстановления равновесия)

и потребитель c2 также начинают обработку p2 сообщений (после восстановления равновесия)

Да , Но как это относится к упорядочению сообщений? Пока нет ошибки, c1 должен завершить обработку текущей записи (скажем, со смещением X), и после перебалансировки c2 продолжит обработку записи со смещением X + 1.

И даже если возникла ошибка, и c1 не удалось выполнить смещение X - c2 будет обрабатывать некоторые уже обработанные сообщения, но порядок будет сохранен для раздела p2.

Разделенный будет только не обрабатываться в порядке, если запись со смещением X1 будет обработана до записи со смещением X2 < X1. Но это никогда не бывает (вы должны, конечно, исключить переработку на основе отказа).

Короче говоря:да, это behavoir дизайна

Если вы строите без гражданства приложения и каждая запись обрабатывается независимо эта работа очень гладко. Если вам нужно состояние, вам нужно будет убедиться, что состояние раздела p2, которое оно передало от потребителя с1 до c2 после перебалансировки (до начала c2 начать обработку данных). Двигаясь состояние на самом деле жесткая проблема, и вы должны рассмотреть возможность использования Кафка Streams - поток обработки библиотеки Кафки, которые могут обработки это автоматически: http://docs.confluent.io/current/streams/index.html

+0

Спасибо. В нашем прецеденте для данного ключа важна обработка сообщения в порядке. может быть несколько условий гонки, таких как после перебалансировки 1) C2, возможно, обработал X + 1 до того, как C1 смог закончить обработку X1 из раздела p2. 2) C1 не смог обработать X1 и C2 закончил обработку X + 1.Спасибо. Мы рассмотрим потоки Kafka. – ravthiru

+0

. Оба сценария, которые вы описываете, невозможны - либо C1 завершил обработку до того, как C2 начнет перехватывать раздел, либо C1 не завершил обработку, а C2 повторит не полностью обработанную запись. Если потребитель C1 не мертв и все еще обрабатывает запись со смещением X, а разделы отменены и переданы C2, когда C1 пытается выполнить смещение X, брокер не допустит этого, потому что C1 больше не владеет секцией, и, таким образом, фиксация сбой исключается. –

+0

И C2 будет обрабатывать запись со смещением X параллельно C1. Таким образом, даже если C1 завершит обработку записи X после того, как C2 закончит запись обработки X + 1, это не имеет значения, потому что C2 обработала запись X до того, как она обработала запись X + 1. Таким образом, вы можете получить только C2 (X), C2 (X + 1) C1 (X). Не уверен, что вторая обработка X в C1 вредна для вашего приложения или нет. –

0

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

+0

Все пользователи в той же группе, это порядок сообщений с одним и тем же разделом во время перебалансировки. – ravthiru