Подмножество разделов журнала изменений и перераспределения потока недоступно, поскольку посредник не работает - как должен вести себя поток?

Question

Моя установка состоит из 3 брокеров kafka (2.11-1.1.1), одного ZK и сервиса java, который использует Streams API.

Служба java использует тему из темы A, выполняет постоянную потоковую операцию (поддерживается журналом изменений и разделом о потоках перераспределения) и записывает в тему B. Семантика EOS включена.

Учитывая, что разделы журнала изменений и перераспределения имеют коэффициент репликации 1, как должно вести себя java-приложение потоков в случае, если один из моих брокеров не работает (например, в моей среде DEV заполнен диск только для одного брокера). Поток будет продолжать потребляться, даже если 1/3 разделов журнала изменений и переразделения недоступны?

РЕДАКТИРОВАТЬ: также учитывая, что темы A, B и __consumer_offsets имеют RF = 3.

В моих журналах java-сервисов я вижу:

2019-01-04 09:14:38,787 UTC WARN kafka-producer-network-thread | trsb-app- 
nonprod.snapshot-14fa12b2-ac15-4ecc-8729-8f6c4a0034a7-StreamThread-2-0_4- 
producer org.apache.kafka.clients.NetworkClient warn | [Producer 
clientId=trsb-app-nonprod.snapshot-14fa12b2-ac15-4ecc-8729-8f6c4a0034a7- 
StreamThread-2-0_4-producer, transactionalId=trsb-app-nonprod.snapshot-0_4] 
Connection to node 1 could not be established. Broker may not be available.
2019-01-04 09:14:38,797 UTC WARN kafka-producer-network-thread | trsb-app- 
nonprod.snapshot-14fa12b2-ac15-4ecc-8729-8f6c4a0034a7-StreamThread-2-1_10- 
producer org.apache.kafka.clients.NetworkClient warn | [Producer 
clientId=trsb-app-nonprod.snapshot-14fa12b2-ac15-4ecc-8729-8f6c4a0034a7- 
StreamThread-2-1_10-producer, transactionalId=trsb-app-nonprod.snapshot- 
1_10] Connection to node 1 could not be established. Broker may not be 
available.

И ничего не потребляется.

В обоих журналах работы брокера я вижу:

[2019-01-04 13:56:56,449] WARN Resetting first dirty offset of trsb-app- 
nonprod.snapshot-store.invoices-changelog-43 to log start offset 99 since 
the checkpointed offset 95 is invalid. (kafka.log.LogCleanerManager$)
[2019-01-04 13:56:56,449] WARN Resetting first dirty offset of trsb-app- 
nonprod.snapshot-store.invoices-changelog-40 to log start offset 103 since 
the checkpointed offset 100 is invalid. (kafka.log.LogCleanerManager$)

Answer 1

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

Answer 2

Поскольку вы используете семантику ровно один раз, для продолжения обработки требуется минимум 3 посредника, поэтому ваше приложение не продолжит обработку, если один из посредников вышел из строя. Прочитайте здесь (см. Раздел processing.guarantee) для получения дополнительной информации об этом:

https://kafka.apache.org/10/documentation/streams/developer-guide/config-streams.html#id25