Как запустить Kafka Canary Consumer

Question

У нас есть очередь Kafka с двумя потребителями, оба читают с одного раздела (сценарий разветвления). Один из этих потребителей должен быть канарейкой и обрабатывать 1% сообщений, в то время как другой обрабатывает оставшиеся 99%.

Идея состоит в том, чтобы принять решение на основе свойства сообщения, например, сообщения. ID или отметка времени (например, mod 100), а также принять или отбросить на основе этого, просто с обратным логином c для канареечного и не канареечного.

Теперь перед нами стоит вопрос, как сделать это надежно Например, перенастроить проценты во время работы и избегать потери сообщений или их обработки дважды. Похоже, что это обостряется до проблемы распределенного консенсуса, чтобы сохранить лог решения c в syn c, чего мы очень хотели бы избежать, даже если бы мы могли просто использовать ZooKeeper для этого.

Это жизнеспособная стратегия, или есть лучшие способы сделать это? Возможно, тот, который избегает консенсуса?

Обновление : К сожалению, кластер Кафки не находится под нашим контролем, и мы не можем вносить какие-либо изменения.

Обновление 2 Задержка сообщений не является большой проблемой, добавлено несколько сотен 100 мс, все в порядке и не будут замечены.

Answer 1

Я не вижу способа изменить «стратегию выборки» на двух машинах без «игнорирования» или двойной обработки записей. Поскольку разные потребители Kafka могут находиться на разных позициях в разделе, а также могут получать новую конфигурацию в разное время, вы неизбежно столкнетесь с одним из 2 сценариев ios:

1. Двойная обработка одна и та же запись на обеих машинах
2. «Пропуск» записи, потому что ни одна машина не считает, что ей «принадлежит», когда она ее видит.

Я бы предложил небольшое изменение в вашей вместо этого архитектура:

• Пусть машина на 99% (не канарейка) соберет все записи, а затем решит для каждой записи, будет ли она обрабатывать ее или принадлежит канарейке
• Если он принадлежит канарейке, отправьте запись во 2-ю топи c (с машины 99%)
• Канарская машина прослушивает только 2-ю топи c и обрабатывает каждая поступающая запись

И теперь у вас есть настройка конвейера, когда решения принимаются только в одной точке, а записи не пропускаются или обрабатываются дважды.

Очевидным недостатком является в некотором роде более высокая задержка на канарейке. Если вы абсолютно не можете мириться с латентностью pu sh, решение о том, какие топики c производить для восходящего потока для производителей? (Я не знаю, насколько это возможно для вас)

Вариант в случае, если 2-я топика c не разрешена

Если (как вы уже сказали выше) вы не может иметь 2-ой топи c, вы все равно можете принять решение только на 99% -ной машине, а затем для записей, которые должны go канарейке, воспроизвести их в исходном разделе с каким-то «маркером» (либо в полезной нагрузке, либо в виде заголовка кафки, на ваше усмотрение). Машина на 99% будет игнорировать любые входящие записи с маркером, и канарская машина будет только обрабатывать записи с маркером.

Опять же, основным недостатком является добавленная задержка.