PD
Ну так ни одна реплика не дает гарантию сохранности данных. В этом и боль. По сути авторы кафки говорят - мы верим, что хотя бы одна реплика fsync сделает.
Есть реальные сценарии с двумя ДЦ, когда этих гарантий не хватает?
Size: a a a
2019 August 20
LV
Раз порядок не важен, то b вернуть в очередь, сдвинуть оффсет на 3
Один из вариантов. Но я вообще не хочу об этом думать. Я хочу семантику "обработал".
LV
А не прочитал.
PD
Один из вариантов. Но я вообще не хочу об этом думать. Я хочу семантику "обработал".
Тогда не забирай пачками...
LV
Есть реальные сценарии с двумя ДЦ, когда этих гарантий не хватает?
Не знаю. Я серьезные проекты, где мне важно обработать все данные, делаю без кафки
LV
Тогда не забирай пачками...
И теряй масштабируемость.
PD
Не знаю. Я серьезные проекты, где мне важно обработать все данные, делаю без кафки
Ну, я вот проектировал для финтеха и нормально там с гарантиями. Лучше, чем у БД.
PD
И теряй масштабируемость.
С чего бы? Масштабируемость по числу партиций, а не по размеру пачки
LV
Число репетиций ограничено.
LV
Я не хочу закладывать в архитектуру ограничения по количеству cpu
PD
Ну, до 200000 нормально живёт. Этого хватит.
PD
Я не хочу закладывать в архитектуру ограничения по количеству cpu
А как связно число партиций и ЦПУ? Сделай обработчики на корутинах и ок
LV
Это у вас столько партий у было?
LV
В одном топике?
PD
Это не у нас, это когда я искал, с какого числа партиций будут проблемы и нашел реальные тесты
PD
Но даже 1000 хватит для масштабируемости почти всегда. Сколько у вас сообщений в секунду планируется?
LV
1000 это меньше 20 машин по 64 ядра
LV
Мне сам подход не нравится.
PD
Ну, а какие варианты для лог-бэйзед очереди. На пульсаре тоже самое будет
PD
1000 это меньше 20 машин по 64 ядра
Ты считаешь по ядру на консамер? А зачем?