Apache kafka компенсирует коммит в топологии Apache Storm - PullRequest
0 голосов
/ 31 января 2019

Я проектирую топологию Apache Storm (с использованием streamparse), построенную с одним носиком (apache kafka spout) и 1 болтом с параллелизмом> 1, который читает сообщения в пакетном режиме из носика kafka и сохраняет сообщения в таблице mysql

Болт чтения сообщений в пакетном режиме.Если пакет успешно завершен, я вручную фиксирую смещение apache kafka.

Когда вставка болта в mysql завершается неудачно, я не фиксирую смещение в kafka, но некоторые сообщения уже находятся в очереди сообщений, которые имеет носикотправил на болт.

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

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

1 Ответ

0 голосов
/ 08 февраля 2019

Я не знаю насчет streamparse, но у меня сложилось впечатление, что вы хотите связать кортежи и записать их как пакет.Допустим, вы записали до смещения 10. Теперь ваш болт получает смещение 11-15, и партия не может записать.Смещение 15-20 ставится в очередь, и вы не хотите обрабатывать их прямо сейчас, потому что это будет обрабатывать партии не по порядку.

Правильно ли это понимание?

Во-первых, я бы отбросил вручнуюсовершать смещения.Вы должны позволить носику справиться с этим.Предполагая, что вы используете storm-kafka-client, вы можете настроить его на фиксацию смещений только после того, как соответствующий кортеж и все предыдущие кортежи были подтверждены.

Что вам, вероятно, следует сделать, это следить за болтом (или даже лучше,в вашей базе данных) какое наибольшее смещение было в неудачном пакете.Затем, когда ваш болт не может записать смещение 11-15, вы можете заставить болт выходить из строя каждый кортеж с помощью offset > 15.В какой-то момент вы снова получите смещение 11-15 и сможете повторить запись пакета.Поскольку все сообщения с ошибкой offset > 15 были неудачными, они также будут повторены и будут доставлены после сообщений в неудачном пакете.

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

...