PD
Хмм, как Кафка теряет данные? Я знаю один кейс, но очень редкий. При правильной настройке.
Size: a a a
2019 August 20
PD
И не знаю решений с большими реальными гарантиями.
LV
Ну или взять пачку, после обработки часть вернуть обратно. И это вполне надёжно
Ну взяли вы пачку в 10 сообщений. На обработку одного уходит 5мс. Закомитили офсет через 1мс. Через 3 упали. Сообщения потеряли. Дальше я любой ваш кейс сведу к этому сценарию до тех пор, пока вы не начнете читать сообщения строго последовательно из партиции и делать коммит офсета по одному сообщению.
PD
Ну взяли вы пачку в 10 сообщений. На обработку одного уходит 5мс. Закомитили офсет через 1мс. Через 3 упали. Сообщения потеряли. Дальше я любой ваш кейс сведу к этому сценарию до тех пор, пока вы не начнете читать сообщения строго последовательно из партиции и делать коммит офсета по одному сообщению.
А зачем закоммитили оффсет через 1мс, а не по факту выполнения пачки?
PD
И зачем читать пачкой, если выполнять все последовательно?
LV
Хмм, как Кафка теряет данные? Я знаю один кейс, но очень редкий. При правильной настройке.
Кафка с настройками по умолчанию не теряет данные сама. Раньше были настройки что могла и потерять, сейчас по умолчанию все ok. Если конечно, fsync хотя бы на одной реплики пройдет.
PD
А не надо использовать настройки по умолчанию. Нигде и никогда
PD
Кафка с настройками по умолчанию не теряет данные сама. Раньше были настройки что могла и потерять, сейчас по умолчанию все ok. Если конечно, fsync хотя бы на одной реплики пройдет.
Да даже если не пройдет - не важно.
LV
Но написать на ней приложение, которое теряет данные, слишком просто. Точнее, муторно решать обратную задачу. Если, конечно, мы хотим иметь в одновремнной обработке больше сообщений, чем партиций
PD
Да тоже нет проблем. Ровно как для любой другой очереди.
PD
И я не вижу кейсов, когда параллельность нужна выше числа партиций. Зачем использовать систему не по назначению?
PD
А вот написать приложение на rmq, которое не теряет данные - вообще не возможно.
LV
А зачем закоммитили оффсет через 1мс, а не по факту выполнения пачки?
Проблема хороший-плохой-хороший. Последовательно меня заставляе т читать кафка. Проблема поддержания идемпотентности во всей системе.
LV
И я не вижу кейсов, когда параллельность нужна выше числа партиций. Зачем использовать систему не по назначению?
Вот и я про тоже. Не надо использовать кафку в каждом приложении))
LV
А вот написать приложение на rmq, которое не теряет данные - вообще не возможно.
А когда он их теряет?
PD
Проблема хороший-плохой-хороший. Последовательно меня заставляе т читать кафка. Проблема поддержания идемпотентности во всей системе.
Это проблема не кафки. Это проблема неверного ее использования, причем специально созданного.
PD
А когда он их теряет?
Да, в общем-то, всегда. Ну плохо у rmq в кластеризации между ДЦ.
LV
Кафку вы между дц с помощью mirror чего-то там синхронизируете?
PD
Вот и я про тоже. Не надо использовать кафку в каждом приложении))
В каждом - нет. Но если нужна надежность, то как-то и нет вариантов. Даже просто БД менее надежны почти во всех кейсах.
У Кафки есть ровно одна проблема - обеспечение транзакционного взаимодействия при записи в БД и в кафку. Но и там есть решения.
У Кафки есть ровно одна проблема - обеспечение транзакционного взаимодействия при записи в БД и в кафку. Но и там есть решения.
PD
Кафку вы между дц с помощью mirror чего-то там синхронизируете?
Нет, конечно. При пинге в 2ms просто пишу реплики в разные ДЦ с учетом rack.