Про старого коня так и сказали разработчики ClickHouse, когда их попросили добавить поддержку etcd, мол, у нас в продакшене это много лет и сейчас смысла что-то менять нет, но с радостью рассмотрим ваш ПР :)
Как я и сказал ранее, брокер уже частично забрал часть функционала на себя и весьма успешно, лично я верю в прямоту рук этих ребят.
Вот классная статья от Conluent, почему нужен этот переход к беззукиперной модели, уже есть четкий роудмап, в том числе упоминают про операционные расходы: www.confluent.io/blog/removing-zookeeper-dependency-in-kafka
Почему пугаю? Это жизнь :) Скорее, рассказываю факты, в том числе на основании личного опыта. Новый компонент — всегда дополнительные ресурсы (пусть даже не такие огромные, как для clickhouse) и дополнительный операционный оверхед (особенно для такого критичного сервиса, как zookeeper, от которого зависят другие сервисы).
По поводу проблем протоколов: cейчас очень распространен Raft, вроде как самый понятный и легкореализуемый протокол, который уже много где используется. Думаю, эти ранние детские болезни уже чуть менее актуальны с его приходом. В zookeeper вообще проприетарный ZAB используется, древний монстр, но вроде как работает исправно. В любом случае, команда Kafka уже успешно переложила часть задач на сам брокер, поэтому этим ребятам я доверяю, продукт ключевой и очень серьезный.
АЛЕКСАНДР МИРОНОВ: Мы же обсуждаем это с точки зрения DevOps? Для любого DevOps-инженера это ещё одна система, которую нужно знать, алертить, мониторить, которая у вас будет падать.
АНАТОЛИЙ СОЛДАТОВ: С другой стороны, ZooKeeper может не только для Kafka использоваться, он вполне может жить в компании в каких-то других системах.
АЛЕКСАНДР МИРОНОВ: А этого, кстати, лучше не делать. Лучше не использовать ZooKeeper для нескольких систем.
Полностью поддерживаю Александра в данном вопросе, дополнительный компонент — это всегда дополнительно операционные расходы на поддержку, обновление, деплоймент, алертинг, мониторинг, и, в принципе, дополнительное железо. Не зря разработчики Кафка активно двигаются в сторону избавления от ZK и пытаются переложить все больше задач по протоколам согласования на сам брокер.
А если учесть, что сейчас модно разворачивать много автономных кластеров под отдельные бизнес-задачи/отделы/домены, то это означает дополнительный кластер ZK на каждую инсталляцию со всеми вытекающими вышеописанными проблемами, какими бы идеальными деплоймент скрипты/плейбуки не были. DevOps-ы и Ops-ы подтвердят :)
То, что попали данные на диски — Кафка не гарантирует.
ACK возвращается клиенту после того, как данные были реплицированы на требуемое количество реплик, а именно в page cache. А дальше уже сама ОС решает, в какой момент времени действительно синхронизировать этот кеш на диск. Хотя стоит отметить, что в Кафке есть настройки для тюнинга этого поведения (например, частота синхронизации), однако сами разработчики рекомендуют полагать на саму ОС в данных вопросах. Поэтому по сути надежность достигается количеством реплик, в которые ведется запись, потому что сброс кеша на диск — накладная операция.
Рекомендую ознакомиться с kafka.apache.org/documentation/#appvsosflush
Как я и сказал ранее, брокер уже частично забрал часть функционала на себя и весьма успешно, лично я верю в прямоту рук этих ребят.
Вот классная статья от Conluent, почему нужен этот переход к беззукиперной модели, уже есть четкий роудмап, в том числе упоминают про операционные расходы: www.confluent.io/blog/removing-zookeeper-dependency-in-kafka
По поводу проблем протоколов: cейчас очень распространен Raft, вроде как самый понятный и легкореализуемый протокол, который уже много где используется. Думаю, эти ранние детские болезни уже чуть менее актуальны с его приходом. В zookeeper вообще проприетарный ZAB используется, древний монстр, но вроде как работает исправно. В любом случае, команда Kafka уже успешно переложила часть задач на сам брокер, поэтому этим ребятам я доверяю, продукт ключевой и очень серьезный.
Полностью поддерживаю Александра в данном вопросе, дополнительный компонент — это всегда дополнительно операционные расходы на поддержку, обновление, деплоймент, алертинг, мониторинг, и, в принципе, дополнительное железо. Не зря разработчики Кафка активно двигаются в сторону избавления от ZK и пытаются переложить все больше задач по протоколам согласования на сам брокер.
А если учесть, что сейчас модно разворачивать много автономных кластеров под отдельные бизнес-задачи/отделы/домены, то это означает дополнительный кластер ZK на каждую инсталляцию со всеми вытекающими вышеописанными проблемами, какими бы идеальными деплоймент скрипты/плейбуки не были. DevOps-ы и Ops-ы подтвердят :)
ACK возвращается клиенту после того, как данные были реплицированы на требуемое количество реплик, а именно в page cache. А дальше уже сама ОС решает, в какой момент времени действительно синхронизировать этот кеш на диск. Хотя стоит отметить, что в Кафке есть настройки для тюнинга этого поведения (например, частота синхронизации), однако сами разработчики рекомендуют полагать на саму ОС в данных вопросах. Поэтому по сути надежность достигается количеством реплик, в которые ведется запись, потому что сброс кеша на диск — накладная операция.
Рекомендую ознакомиться с kafka.apache.org/documentation/#appvsosflush