Имея многопоточный потребитель Кафки на раздел, можно ли и рекомендуется, если так, какой-либо фрагмент образца?

Question

Мы используем версию Kafka 0.9 и имеем большое количество сообщений, помещенных в определенный раздел в теме kafka. И в этой теме есть несколько таких разделов. У нас есть один потребитель, назначенный для раздела в этом разделе, и мы поддерживаем смещение вручную в разделе раздела в внешнем хранилище данных. Я хотел знать, начнем ли мы получать действительно большое количество сообщений в разделе темы, возможно ли, чтобы потребитель, столкнувшись с разделом тем, был многопоточным. Поскольку может оказаться невозможным, чтобы экземпляр пользователя, назначенный разделу, смог закончить обработку всех записей в промежутке времени, который мы хотим завершить. Возможно ли иметь такой многопоточный потребитель с разделом. Рекомендуется ли это? Также, если ответ «ДА», то как несколько потоков могут выполнять управление смещением, потому что все эти потоки имеют дело с сообщениями внутри одного раздела. Доступен любой фрагмент образца?

Пожалуйста, обратите внимание: Я спрашиваю о «потребитель имеет дело с одним разделом в теме», я не глядя на группы потребителей на тему по разделам в нем.

Answer 1

Что вы можете сделать, есть 1 Thread, обрабатывающий потребление сообщений для этого раздела и кучу рабочих, обрабатывающих эти сообщения. Есть несколько проблем, с которыми вы сталкиваетесь с этим решением (например, процесс сообщений может быть не в порядке), а также сбой и повторные попытки вы должны обрабатывать их отдельно, поскольку фиксация смещения будет выполняться потребителем, когда (1) он передает сообщения рабочим или (2) работники должны будут уведомить потребителя, когда обработка завершена, чтобы потребитель мог сохранить список (упорядоченный по смещению в начале), и смещение будет совершаться только тогда, когда его следующее смещение после последнее зафиксированное смещение (и удалено из списка). Это решение имеет недостаток, что может быть несколько смещений, ожидающих фиксации, потому что есть медленный рабочий (или тяжелое сообщение), и если потребитель спустится в следующий раз, когда вы будете обрабатывать сообщения (в любом случае есть обходные пути для этого).

Надеюсь, это поможет!