проблемы были на python в реализации транзакционной модели. Если точнее, консамер видил сообщения, даже после abort_transaction. Предположили что это библиотека confluent для питона не совершенна. Быстро перенесли алгоритм на Java, проблема осталась.(( Как только запускается продюсер 100.000 сообщений в одним топик. Консольный потребитель подключенный к топику со свойством isolation.level=read_commited сразу видит сообщения которые заливаются, хотя по логике из документации не должен. Вопрос, может здесь какой метод продюсера играет роль на отправку сообщений в топик?
Делаем так:
init.transaction
begin.transaction
Producer.Send(Messages) -цикл 100.000 сообщений.
Если все ок, commit.transaction
Иначе abort.transaction.
вот в доке пример описан всё должно работать https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html
Благодарю. Проверим, напишу по итогу, помогло или нет..
Приветствую всех. Проверили пример из документации у себя. Есть такая особенность. Если сообщений не много и они менее 1 Кб, то все работает как надо. Но если сообщения 1Кб и Более, то ситуация не меняется: За основу взяли пример из документации. Заменили только алгоритм добавления сообщения: producer.beginTransaction(); String MessageData = GetDataBySize(1024); for (int i = 0; i < 10000; i++) producer.send(new ProducerRecord<>("topic03", Integer.toString(i), String.format("Message %s %s", i+1, MessageData))); и вместо commit.transaction поставили сразу abort.transaction. При таких условиях, консамер не должен был увидеть вообще ни одного сообщения. Но увы все равно были видны((. Может какие то еще настройки не учитываем?
Здесь может сама архитектура выстроенная влияет? Кластер из 3-х Брокеров и 1 зукипер?
да вроде от количества брокеров это вообще никак не должно зависеть transactional.id установлен? я единственное что по себе вспомнил - у нас ключ всех сообщений в транзакции - один, соответственно, всё они в одной партиции (не знаю, влияет ли это) может, бага в самом брокере конкретной версии? если смотреть онлайн по смещениям, то коммит выглядит как ещё одно сообщение, которое не видно на консьюмере. так можно понять, прилетает ли вообще коммит как вариант - попробуйте тестовый стенд собрать с дефолтными настройками, на него натравить простейший тест - там посмотреть, вдруг какое хитрое влияние инфраструктуры
transactional.id установлен? При каждом запуске новое значение. В принципе по этой части проверяли. И одно значение так же ставили. Не влияет. Пока будем тогда рассматривать 2 версии, либо это версия броекров Кафки. Либо это наша архитектура. Так как проверили уже и на java и на python результат один, транзакции не работают корректно. Благодарю за направления. Будем дальше думать и искать решение. Найдем, отпишусь в чем было дело.
Обсуждают сегодня