Я вижу, вы имеете в виду мой комментарий ...
Что касается ваших пуль
решение должно быть приложением JVM
Все перечисленные файлы основаны на Java
, если тема назначения не существует, создает ее
Это зависит от версии брокера Kafka, поддерживающейAdminClient API.В противном случае, как говорится в документации MirrorMaker, вам следует создать тему назначения перед зеркалированием, в противном случае вы либо получите (1) отказ в создании, так как автоматическое создание темы отключено (2) проблемы с просмотром «согласованных» данных, так как была создана настроенная тема по умолчанию.
При этом, по умолчанию, MirrorMaker не "распространяет" конфигурацию тем самостоятельно.Когда я смотрел, MirrorTool так же не делал.Я не посмотрел внимательно на Mirus, но, кажется, только количество разделов сохраняется
Confluent Replicator копирует конфигурации, разделы и использует AdminClient.
Репликатор, MirrorTool и Mirus основаны на API-интерфейсе Kafka Connect.И KIP-382 будет также
Создайте свое собственное приложение (на основе функциональности Kafka Streams
Kafka Streams может общаться только from()и to() a одиночный кластер .
Вы могли бы также просто использовать MirrorMaker, потому что это уже оболочка вокруг производителя / потребителя и поддерживает один кластер к другому. Если вам нужны пользовательские функции,это то, для чего нужен интерфейс MessageHandler.
На более высоком уровне API-интерфейс Connect также достаточно настраивается, и исходный код MirrorTool, который я нахожу действительно простым для понимания.
Решение должно иметь возможность добавлять префиксы / суффиксы к именам тем назначения
Каждый может сделать это, но MirrorMaker требует дополнительного / специального кода. См. пример по @ gwenshap
перезагрузите и примените конфигурации на лету, если они изменились
Это сложный вопрос ... Обычно вы просто отклоняете процесс Java, потому что большинство конфигурацийns загружаются только при запуске.Исключением является whitelist или topics.regex для поиска новых тем для потребления.
KIP-382
Трудно сказать, что будет принято.Хотя он и написан, и я лично думаю, что он достаточно ограничен, он несколько противоречит цели иметь Replicator for Confluent.поскольку подавляющее большинство коммитов и поддержки Kafka происходит из Confluent, это конфликт интересов
Используя Replicator, у него есть несколько дополнительных функций, которые позволяют осуществлять аварийное переключение потребителей в случае сбоя центра обработки данных,так что это все еще полезно до тех пор, пока кто-то не обратится к этим вызовам API Kafka в другие решения
MirrorTool также имеет KIP, но, похоже, он был отклонен в списке рассылки с объяснением: «Kafka Connect является подключаемой экосистемой,могу пойти дальше и установить это расширение зеркалирования, но оно не должно быть частью основного проекта Kafka Connect ", или, по крайней мере, так я его прочел.
Что "лучше" - это вопрос мнения, и есть еще другие варианты (на ум приходят Apache Nifi или Streamsets). Даже используя kafkacat и netcat, вы можете взломать кластерную синхронизацию.
Если вы платите за корпоративную лицензию, в основном за поддержку, то вы также можете использовать Replicator.
Одна вещь, которая может быть важна, чтобы указать на MirrorMaker, который я обнаружил, что если вы зеркально отражаете тему, которая не использует DefaultPartitioner, то данные будут перетасовываться в DefaultPartitioner в целевом кластере, если вы не сконфигурируете конечного производителя Kafka для использования того же значения раздела или класса разделителя, что и для исходного Kafka Producer.