Кафка Миграция сообщений

Question

В настоящее время мы работаем на Apache Kafka 0.10.1.1.Мы переходим на Confluent Platform 5.X.Новый кластер полностью настроен на другой набор физических узлов.

Пока мы уже работаем над обновлением API, наше приложение использует spring-boot, мы пытаемся выяснить, как мы переносим сообщения?Мне нужно поддерживать тот же порядок сообщений в целевом кластере.

1. Можно ли просто скопировать сообщения?
2. Нужно ли повторно публиковать сообщения в целевом кластере для успешного хранения?
3. Что еще можно сделать?

Answer 1

Confluent включает в себя инструмент под названием Replicator, который, будучи корпоративной функцией, можно использовать для 30-дневной пробной версии для выполнения миграции данных.

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

FWIW, я бы предложил сначала добавить соответствующие компоненты Confluent 3.x в существующий кластер,если возможно.Или даже просто сначала обновите брокеров.Я хочу сказать, что «мигрировать в Confluent» нечего, поскольку Kafka - это не то, что меняется, вы просто добавляете вокруг него другие процессы, такие как Реестр схем или Центр управления

Answer 2

Предполагается, что определение темы в новом кластере точно такое же (т. Е. Nbr разделов, сохранение и т. Д.), А хеширующая функция источника на ключе сообщения доставит ваше сообщение в тот же раздел (будет обломом)если у вас есть нулевые ключи, потому что они окажутся в случайном разделе), вы можете просто извлечь из самого раннего из вашей старой темы о брокере kafka и создать новую тему в новом кластере с помощью специального потребителя / производителя или какого-либо инструмента, подобного logstash.

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

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

Однако процесс MirrorMaker сохранит и использует ключ сообщения для разделения, так что порядоксохраняется для каждого ключа.

Примечание: какуказано в первом решении и, как сказал cricket_007, оно будет работать только в том случае, если вы использовали разделитель по умолчанию и хотите продолжать использовать его в новом кластере.

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

Отказ от ответственности Это чисто теоретическое.Я никогда не пробовал переход с такими жесткими требованиями.