Прошу прощения, поясните что такое AP и CP (почитать)

Consistency vs availability

CAP теорема, вкратце суть в том, нужна ли тебе гарантированно консистентная система ценой отказа от доступности, или наоборот - система будет доступной, но ценой расхождения (неконсистентности).

Сразу скажу, что Кафка заточена под AP решение.

у кафки появились ручки для гарантированного флуша сообщения на диск перед отправке ack?

строгого C сложно добиться скорее. Вот допустим у меня 3 брокера. делаю send . допустим все 3 записали в свой лог даже и клиенту пришел ответ, что все записали (но не сбросили на диск при этом). выключаем питание на всех 3. C пропадает. не так ли? т.е без durability нету C.

да по-моему давно уже.

мне известен только флуш по интервалу времени, а не по событию

есть 2 настройки. 1) как часто флушить по времени 2) как часто в терминах количества сообщений

спасибо, значит ничего не поменялось

это очень странный пример. если тебе брокер вернул успех, то это означает, что копия данных на диске у N реплик. и верь или нет, но это не гарантирует ту самую строгую C.

нет таких гарантий. в кафке durability через фоловеров. на диск они не обязаны скинуть. никто из них

есть параметр log.flush.interval.messages . он определяет как часто скидывать на диск.

Вот именно поэтому Кафка AP, а не CP.  Я к тому, что даже если ты гипотетически представить что репликация синхронная, все равно этого недостаточно.

и вот второй log.flush.interval.ms

А мне кажется, что A тоже строго говоря нету . Вот если посмотретьна определение Every request receives a (non-error) response, without the guarantee that it contains the most recent write .  Т.е она всегда должна ответить без ошибки, но вот если у нас скажем 3 брокера и мы пишем с acks = 1 т.е пишем только на лидера. Допустим у нас такая ситуация, что 2 других брокера упали и жив только лидер. мы пишем на него  X минут. он падает после этого, но поднимаются остальные 2( а это продолжает лежать ). они ведь не смогут стать лидерами т.к у нас по умолчанию Unclean Leade rElection равно false. Все. получаем, что мы с тем топиком не можем работать

кстати значение по умолчанию для log.flush.interval.messages = Long.MaxValue

А если упали все три, да ещё и датацетр потом сгорел и метеорит сверху - тогда ваще.

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

а для интервала в 60 секунд!

т.е по умолчанию fsync 1 раз в 60 секунд! Вот это номер