Я пытаюсь понять ZooKeeper, как он работает и что он делает. И я совершенно смущен. Есть ли приложение, сопоставимое с ZooKeeper?
Если вы знаете, то как бы вы описали ZooKeeper неспециалисту. (Учитывая, что я один)
Я пробовал apache wiki, zookeeper sourceforge... но я до сих пор не могу с ним связать. Любая помощь будет оценена!
Я только что прочитал через http://zookeeper.sourceforge.net/index.sf.shtml, так что нет ли таких сервисов? Это просто, как просто репликация серверной службы?
Вкратце, ZooKeeper помогает вам создавать распределенные приложения.
Вы можете описать ZooKeeper как реплицированную службу синхронизации с возможной согласованностью. Это устойчиво, поскольку сохраненные данные распределяются между несколькими узлами (этот набор узлов называется "ансамблем" ), и один клиент подключается к любому из них (то есть к определенному "серверу" ), перенося, если один node не работает; пока работает строгое большинство узлов, ансамбль узлов ZooKeeper жив. В частности, мастер node динамически выбирается консенсусом внутри ансамбля; если мастер node не работает, роль мастера переносится на другой node.
Мастер - это полномочия для записи: таким образом, записи могут быть сохранены в порядке, т.е. записи линейны. Каждый раз, когда клиент записывает в ансамбль, большинство узлов сохраняют информацию: эти узлы включают сервер для клиента и, очевидно, мастер. Это означает, что каждая запись делает сервер актуальным с мастером. Это также означает, что вы не можете иметь одновременную запись.
Гарантия линейной записи является причиной того, что ZooKeeper не работает хорошо для записи-доминантных рабочих нагрузок. В частности, он не должен использоваться для обмена большими данными, такими как носители. Пока ваше общение связано с общими данными, ZooKeeper помогает вам. Когда данные могут быть записаны одновременно, ZooKeeper фактически мешает, поскольку он налагает строгий порядок операций, даже если это не является строго необходимым с точки зрения авторов. Его идеальное использование - это координация, при которой сообщения обмениваются между клиентами.
Здесь ZooKeeper превосходит: чтение является одновременным, поскольку они обслуживаются определенным сервером, к которому подключается клиент. Однако это также является причиной возможной согласованности: "просмотр" клиента может быть устаревшим, поскольку мастер обновляет соответствующий сервер с ограниченной, но undefined задержкой.
Реплицированная база данных ZooKeeper содержит дерево znodes, которые представляют собой сущности, грубо представляющие узлы файловой системы (считая их как каталоги). Каждый znode может быть обогащен байтовым массивом, который хранит данные. Кроме того, каждый znode может иметь под собой другие znodes, фактически формируя внутреннюю систему каталогов.
Интересно, что имя znode может быть последовательным, что означает, что имя, которое клиент предоставляет при создании znode, является только префиксом: полное имя также задается порядковым номером, выбранным ансамблем. Это полезно, например, для целей синхронизации: если несколько клиентов хотят получить блокировку ресурсов, они могут каждый раз создавать последовательный znode в местоположении: тот, кто получает самое низкое число, имеет право на блокировку.
Кроме того, znode может быть эфемерным: это означает, что он уничтожается, как только клиент, который его создал, отключается. Это в основном полезно для того, чтобы знать, когда клиент терпит неудачу, что может иметь значение, когда у самого клиента есть обязанности, которые должен принять новый клиент. На примере блокировки, как только клиент, имеющий блокировку, отключается, другие клиенты могут проверить, имеют ли они право на блокировку.
Пример, связанный с отключением клиента, может быть проблематичным, если нам нужно периодически опросить состояние знодов. К счастью, ZooKeeper предлагает систему событий, в которой часы могут быть установлены на znode. Эти часы могут быть настроены на запуск события, если znode специально изменен или удален, или под ним создаются новые дети. Это явно полезно в сочетании с последовательными и эфемерными вариантами для znodes.
Канонический пример использования Zookeeper - это вычисление распределенной памяти, где некоторые данные распределяются между клиентскими узлами и должны быть доступны/обновлены очень осторожным способом учета синхронизации.
ZooKeeper предлагает библиотеке создавать ваши примитивы синхронизации, в то время как возможность запуска распределенного сервера позволяет избежать проблемы с одной точкой отказа, когда вы используете централизованный (брокерский) репозиторий сообщений.
ZooKeeper - это функция-свет, что означает, что такие механизмы, как выборы лидеров, блокировки, барьеры и т.д., еще не присутствуют, но могут быть написаны над примитивами ZooKeeper. Если C/Java API слишком громоздкий для ваших целей, вы должны полагаться на библиотеки, созданные на ZooKeeper, такие как cages и особенно curator.
Официальная документация отдельно, что довольно хорошо, я предлагаю прочитать главу 14 Hadoop: The Definitive Guide, в которой есть ~ 35 страниц, объясняющих, по сути, что делает ZooKeeper, после на примере службы конфигурации.
Вот техническая беседа которая представляет собой введение в Apache ZooKeeper от Camille Fournier, который является техническим директором RentTheRunway. Я надеюсь, что это будет полезно.
Вы можете прочитать эту статью
ZooKeeper: Координация бездействия для интернет-систем
Написано двумя Yahoo! Инженеры
Zookeeper - один из лучших серверов с открытым исходным кодом и сервис, который помогает надежно координировать распределенные процессы. Zookeeper - это система CP (см. Теорему CAP), которая обеспечивает согласованность и разделение. Репликация состояния Zookeeper во всех кивках делает его в конечном итоге последовательным распределенным сервисом.
Кроме того, любой новоизбранный лидер будет обновлять своих последователей отсутствующими предложениями или мгновенным выстрелом государства, если у последователей будет много предложений.
Zookeeper также предоставляет API, который очень прост в использовании. Это сообщение в блоге Примеры Java API Java Zookeeper содержит примеры, если вы ищете примеры.
Итак, где мы это используем? Если вашему распределенному сервису требуется централизованное, надежное и последовательное управление конфигурацией, блокировки, очереди и т.д., Вы найдете Zookeeper надежным выбором.
Вот хорошая книга, которую я нашел в Zookeeper: Apache ZooKeeper Essentials
Zookeeper - это централизованный сервер с открытым исходным кодом для поддержки и управления информацией о конфигурации, соглашениями об именах и синхронизации для распределенной среды кластера. Zookeeper помогает распределенным системам снизить сложность управления, обеспечивая низкую задержку и высокую доступность. Zookeeper первоначально был подпроектом для Hadoop, но теперь он является независимым проектом Apache Software Foundation на уровне высшего уровня.
Для SpringBoot, функционально, Zookeeper = Spring Cloud Config + Eureka + Ribbon + Zuul
Конфигурация: распределенная конфигурация
Eureka: Service Discovery, экземпляры могут быть зарегистрированы в Zookeeper, и клиенты могут обнаружить экземпляры с помощью Spring -managed beans
Лента: балансировка нагрузки клиентской стороны через Spring Cloud Netflix
Zuul: динамический маршрутизатор и фильтр через Spring Cloud Netflix
Я понимаю ZooKeeper в целом, но имел проблемы с терминами "кворум" и "разделить мозг", поэтому, возможно, я могу поделиться своими выводами с вами (я считаю себя неспециалистом).
Скажем, у нас есть кластер ZooKeeper из 5 серверов. Один из серверов станет лидером, а остальные станут последователями.
Эти 5 серверов образуют кворум. Кворум просто означает, что "эти серверы могут голосовать, кто должен быть лидером".
Таким образом, голосование основано на большинстве. Большинство просто означает "более половины", поэтому более половины числа серверов должны согласиться, чтобы конкретный сервер стал лидером.
Итак, есть такая плохая вещь, которая может случиться под названием "расколотый мозг". Разделенный мозг - это просто, насколько я понимаю: кластер из 5 серверов разбивается на две части или позволяет называть его "серверными командами", возможно, одной частью из двух и трех из трех серверов. Это действительно плохая ситуация, как будто обе "серверные команды" должны выполнить конкретный заказ, как бы вы решили, какая команда должна быть предпочтительнее? Возможно, они получили различную информацию от клиентов. Поэтому очень важно знать, что "серверная команда" по-прежнему актуальна, и которую можно/следует игнорировать.
Большинство из них также являются причиной использования нечетного числа серверов. Если у вас 4 сервера и раздвоенный мозг, где 2 сервера разделены, то обе "серверные команды" могут сказать "эй, мы хотим решить, кто лидер!". но как вы должны решить, какие 2 сервера вы должны выбрать? С 5 серверами это просто: команда сервера с 3 серверами имеет большинство и может выбрать нового лидера.
Даже если у вас всего 3 сервера и один из них не работает, остальные 2 все еще составляют большинство и могут согласиться, что один из них станет новым лидером.
Я понимаю, как только вы подумаете об этом некоторое время и понимаете термины, которые это не так сложно. Надеюсь, это также поможет любому понять эти условия.