Comments 16
Спасибо за пост. Почему стоит использовать zookeeper, а не etcd?
Java api Зукипера гораздо удобнее чем у etcd. Apache Curator на самом деле великолепен.
Вероятность что Гугл решит убить etcd гораздо выше чем вероятность что Apache решит убить Зукипер.
Мигрировать на другую БД это всегда сложно, дорого и чевевато багами в старом проверенном коде. Оставаться на неподдерживаемой БД тоже плохо.
etcd по моему опыту намного более чувствителен к IO и очень плохо переживает ситуации типа "одна из нод начала подтупливать", Zk в этом отношении куда стабильнее.
проблема №1: отсутствие аудита
проблема №2: очень непривычное поведение ACL (если вы хотите, чтобы к какой-то ноде и её чилдам не было чтения/записи, то это нужно запрещать «вручную» на всем уровне вложенности)
проблема№3: если вам не нужен анонимный доступ, то его отключение может быть сложным/невозможным
Если для вас три пункта не критичны, то ZK хороший вариант.
"Незаслуженно забытый ZooKeeper"
заслуженно забытый и не нужный. Таже Кафка скоро от него избавиться
Можете подробнее? Не совсем шарю в этой теме. В статье вроде бы привели довольно полезные кейсы использования. На что обменять zookeeper и главное почему?
На настоящий момент обещают не раньше конца 2021, но есть нюанс…
Кафку так просто не вырезать, я в курсе что она тоже на джава.
Допустим на примере Зукипера.
Он требует не сильно больше памяти чем размер снапшота данных. Хипа примерно +30% от размера снапшота ему хватит.
С учетом что снапшот в несколько гигабайт это очень много (больше сотни серверов точно нужно чтобы так нагрузить при минимально разумном написании кода) это не выглядит большими расходами.
Вы считаете это пожиранием?
PS: Рекомендации по хипу надо проверять на вашем паттерне нагрузки и обязательно мониторить. Не стоит просто так катить в прод без мониторинга. +30% это хорошая отправная точка.
Когда у вас одно такое приложение, это норм. Даже десяток можно настроить. Но когда за пол сотни набегает и разрабы турбонаддувом выжирают память и не собираются указывать корректные значения памяти, потому что недостаточно квалификации, то надоедает рутина по профилированию и нагрузочному тестированию каждой поделки. Это даже не моя основная задача, а основные задачи при этом страдают. Субъективная нелюбовь к джава, просто жалоба в пустоту.
Разработчики сами по очереди мониторят и чинят свой софт. ООМ это типичнейшая проблема которая всегда чинится руками разработчиков того что ООМнулось. За пару месяцев дежурств со звонками по ночам мол там твое приложение оомится и работать не хочет все настраивается около идеально. Руками самих разработчиков этих приложений.
Написать плохо, так что софт ест слишком много железа, можно на любом языке. Тут скорее пусть лучше будет плохо на джаве написанно, чем на плюсах. Джаву переписать хорошо проще и быстрее чем плюсы.
Незаслуженно забытый ZooKeeper