ну так собственно в этом то и вопрос был
как это все делается и от чего зависит))

ZK тоже можно по разному использовать. Можно AP, а можно CP.

2 свойста это определяют acks и min.insync.replicas

Всем привет!
Начал изучать кафку, и возникло несколько вопросов. Если это где-то уже обсуждалось - направьте, пожалуйста.

1. Запускаю простое приложение, которое пишет сообщения в кафку быстрее, чем читает. Версия приложения - 0.1, подхватывается кафкой и присваивается в кач-ве названия консьюмер группы;
2. Останавливаю приложение. Поднимаю его версию до 0.2 и запускаю. Создаётся новая консьюмер группа, а не успевшие попасть в консьюмер сообщения с прошлого раза так и остаются висеть в очереди. В итоге:

consumer group   --  state    --  overall lag  
kafkaapp-v0.1       --     -        --  21585
kafkaapp-v0.2       --  Active  --  -

Причина понятна: https://stackoverflow.com/questions/58928487/kafka-consumer-not-consuming-from-beginning
Одно из путей решения - это сбросить оффсет группы. Не заставит ли это кафку законсьюмить сообщения дважды? Но группа kafkaapp-v0.1 уже не в ходу: нужно как-то "перекинуть" сообщения в kafkaapp-v0.2?

Мог ошибиться где-то с терминами. Если так, поправьте. Спасибо!

Оставить название консьюмер группы прежним можно? То есть не изменять его с версией приложения

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

When an application is updated, the application.id should be changed unless you want to reuse the existing data in internal topics and state stores.

Так, это немного не то объяснение) Не могу найти другое, где более чётко объяснялся мотив. В любом случае, если название группы можно не менять - не буду

Но даже если работать с одной группой, то сбросить ей оффсет не получится, пока активен консьюмер:

Consumer group 'kafkaapp-v0.1' is still active and has following members: [(memberId=kafkaapp-v0.1-log-consumer-...]. Make sure to stop all running application instances before running the reset tool.

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

Лучше наверно просто по порядку процессить, или вам надо какие-то важные сообщения обработать в обход лага?

На самом деле, очерёдность сообщений, прилетающих в консьюмер, не сильно важна. Главное, чтоб все сообщения были доставлены

По поводу гарантированной доставки копаю эту статью: https://habr.com/ru/company/tinkoff/blog/481784/

Николай да верно кафка по умолчанию CP
но тем не менее настройка этих 2х свойств acks и min.insync.replicas не дадут вам истинного AP
потому что кафка использует raft протокол а он опирается на выраженного лидера соот если
лидер отвалится то придется ждать выбора нового
к примеру если взять Кассаднру то она использует протокол Paxos он позволяет иметь много лидеров по сути в кассандре каждая нода является лидером и это дает настоящее AP

Не. Паксос тоже с лидером. Это известное заблуждение, что многие думают, что паксос без лидера.этих паксосов штук 200. какой-нибудь византийский без лидера, но скажем, что большинство из них с лидером.

если кафка с зукипером, то нет в ней и рафта, а есть ZAB

в касанде нет лидера, но это не из-за паксоса, а потому, что там паксоса вообще нет. она лидер лесс, если не используются транзакции. Они прикрутили паксос только для LWT

вопрос хороший вы подняли. Можно ли считать, что есть A, когда происходит смена лидера.

Лучше не статью читать, а комментарии к ней, там гораздо больше правильных мыслей.
Ну и проверить, насколько max.inflight=1 совместим с требуемой производительностью.

Добрый день, коллеги! Скажите пожалуйста, а кто то покупал confluent ? Это дорого? И нужен он вообще или в community все можно самому собрать?

Где то на просторах этого чата встречал сообщение, что пока купить лицензии confluent-а в России можно, но в 2021 могут быть трудности с дальнейшим продлением и работой всего этого.
@gamussa, поправь, если ошибаюсь

Хотя возможно с лицензиями и сейчас для России проблема