Size: a a a

2020 September 21

N

Nikolay in pro.kafka
Вячеслав
А если упали все три, да ещё и датацетр потом сгорел и метеорит сверху - тогда ваще.

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

В

Вячеслав in pro.kafka
Можно. Всё зависит от требований и принятия рисков.
источник

В

Вячеслав in pro.kafka
Если надо "мы лучше все сдохнем - но если уж записали, то точно записали" - то кафка-подобную очередь и на базе таблички в кластере оракла можно сделать.
источник

N

Nikolay in pro.kafka
ага. в oracle только уже есть готовые очереди. Но там не будет такой большой пропускной способности как в кафке , даже на ssd. На ssd там можно выжать ну 20 тыс commit в секунду , а в кафке можно и 200 тыс сообщений в секунду .
источник

SB

S B in pro.kafka
Nikolay
А мне кажется, что 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. Все. получаем, что мы с тем топиком не можем работать
это опять же - не туда пример. суть в том, что если мастер свалился, подхватит его реплика (если она есть; если ее нет, то система не распределенная в том смысле, в котором CAP хочет распределенную систему и наличие других брокеров в кластере не дают ее таковой __с этой точки зрения__). но реплика, как ты сам успел заметить, не 1 к 1 с мастером в общем случае в виду ряда фундаментальных причин, одна из которых - принципиально асинхронная репликация. есть и другие.
источник

SB

S B in pro.kafka
то есть, CAP это теорема, моделирующая ситуацию идеальным условиями. математика есть математика. на практике, когда говоря, что у нас "АР" система, никто не подразумевает, что не существует ни одного сценария, когда АР не выполняется. по крайней мере, я таких систем не знаю. подразумевается, что базовый функционал работает в режиме АП при условии, что система правильно сконфигурирована (в нашем случае это реплики).
источник

SB

S B in pro.kafka
отсюда видно, что один из самых простых (и тупых!) способов выжать из Кафки СР - это держать реплику == 1. тогда система консистентна в каждый момент времени тривиальным образом и в случае, если произойдет отказ сети (P == partitioning == network partitioning == какой-то брокер кластера перестал быть доступен для других брокров кластера), то одновременно произойдет и отказ от обработки новых запросов.
источник

N

Nikolay in pro.kafka
S B
это опять же - не туда пример. суть в том, что если мастер свалился, подхватит его реплика (если она есть; если ее нет, то система не распределенная в том смысле, в котором CAP хочет распределенную систему и наличие других брокеров в кластере не дают ее таковой __с этой точки зрения__). но реплика, как ты сам успел заметить, не 1 к 1 с мастером в общем случае в виду ряда фундаментальных причин, одна из которых - принципиально асинхронная репликация. есть и другие.
В кафке нет мастера ведь. Есть лидер и фоловеры. И вы согласны , что есть ситуации , когда фоловеры ну вот просто физически не смогут стать лидерами , если они были out of sync ?
источник

SB

S B in pro.kafka
Nikolay
В кафке нет мастера ведь. Есть лидер и фоловеры. И вы согласны , что есть ситуации , когда фоловеры ну вот просто физически не смогут стать лидерами , если они были out of sync ?
Да это уже частности, которые мало кого интересуют. Это уже крайние случаи, которые можно долго смаковать, но я не настолько знаю Кафку. Суть в том, какие принципиальные решения положены в ее основу и на что они целятся. Все что я выше пытался показать, так это то, что Кафка и вправду заточена под AP, не более этого.
источник

SB

S B in pro.kafka
насколько хороша Кафка как АР и сколько есть способов ее сломать - этот вопрос я не пытался даже обсуждать.
источник

SB

S B in pro.kafka
(но мой экспириенс с Кафкой показывает, что достаточно хороша и сломать ее и правда непросто).
источник

N

Nikolay in pro.kafka
S B
Да это уже частности, которые мало кого интересуют. Это уже крайние случаи, которые можно долго смаковать, но я не настолько знаю Кафку. Суть в том, какие принципиальные решения положены в ее основу и на что они целятся. Все что я выше пытался показать, так это то, что Кафка и вправду заточена под AP, не более этого.
Принципиальное решение по мне так одно - durability через фоловеров. А вы какие ещё видите принципиальные идеи ?
источник

IR

Ivan Rasikhin in pro.kafka
Ну кстати durability то в кафке не  гарантировано из коробки(только сетевой ack)
источник

SB

S B in pro.kafka
Nikolay
Принципиальное решение по мне так одно - durability через фоловеров. А вы какие ещё видите принципиальные идеи ?
Durability здесь лишний элемент. Он просто не нужен, это дополнительная деталь, которая никак не влияет на AP / CP дихотомию. Есть дурабилити или нет - принципиальный взаимоисключающий выбор остается. А вот асинхронная репликация или особенности сетей и (как следствие) невозможность в общем случае достигнуть консенсуса даже для таких простых вещей, как подтверждение обработки сообщения (коммит) - подобные факторы и влияют.
источник

N

Nikolay in pro.kafka
Ivan Rasikhin
Ну кстати durability то в кафке не  гарантировано из коробки(только сетевой ack)
Это такое durability  в пределе . Чем больше фоловеров , тем больше дьюрабилити )
источник

SB

S B in pro.kafka
Конкретно с Кафкой: асинхронная репликация, следствие агрессивного батчинга, без которого throughput был бы гораздо ниже, чем то, что Кафка реально способна выдать, да и вообще все особенности Кафки, где слово "асинхронно" участвует. например, запись в топик (если не рассматривать частные случаи, когда буффер настроен на одно сообщение - верный способ угробить перфоманс).
источник

AZ

Alexey Zabolotniy in pro.kafka
Всем привет! Можно глупый вопрос?
У меня не получается вычитать ВСЕ сообщения из топика. Можете подсказать на какие параметры нужно обратить внимание?

Для наглядности: в топике 250 сообщений (44366 Bytes)
Вы
источник

AZ

Alexey Zabolotniy in pro.kafka
Выполняю consumer.poll(Duration.ofMillis(1000))
источник

AZ

Alexey Zabolotniy in pro.kafka
мне прилетает только 165 сообщений
источник

AZ

Alexey Zabolotniy in pro.kafka
с другими топиками тоже ерунда 10000 сообщений из 25000 получаю
источник