Запуск отдельного коннектора kafka s3 в автономном и распределенном режиме - PullRequest
1 голос
/ 23 января 2020

У меня есть kafka topi c "mytopi c" с 10 разделами, и я хочу использовать разъем приемника S3 для приема записей в корзину S3. В целях масштабирования он должен работать на нескольких узлах для записи данных разделов параллельно в одно и то же ведро S3.

В Kafka connect руководство пользователя и на самом деле во многих других блогах / руководствах рекомендуется запускать работники в распределенном режиме вместо автономного для достижения лучшей масштабируемости и отказоустойчивости:

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

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

  1. Если я буду работать в распределенном режиме, у меня будет только 1 рабочий, обрабатывающий все разделы, поскольку это считается одной задачей соединителя.
  2. Вместо этого я должен работать в автономном режиме в нескольких узлах. В этом случае у меня будет группа потребителей, и я получу параллельную обработку разделов.
  3. В вышеописанном автономном сценарии у меня действительно будет отказоустойчивость: если один экземпляр умрет, группа потребителей будет перебалансирована, а другие автономные работники будут обрабатывать освобожденные разделы.

Правильно ли мое понимание или я что-то упустил?

К сожалению, я не смог найти много информации по этой теме c, кроме этого обсуждения групп Google , где автор пришел к тому же выводу, что и я.

Ответы [ 2 ]

1 голос
/ 24 января 2020

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

1 голос
/ 23 января 2020

Теоретически это может сработать, но вы в конечном итоге получите sh для нескольких машин, имеющих в основном одинаковые файлы конфигурации, и просто не будете использовать команду connect-distributed вместо connect-standalone.

Вам не хватает части о перебалансировке задач сервера Connect, которая взаимодействует через REST-порты сервера Connect

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

...