1. Создать фон
Сегодня эпоха распределенных, кластерных, облачных вычислений и прочих летающих по небу терминов. Важным фактором, вызывающим эту ситуацию, является то, что вычислительная мощность одной машины больше не может удовлетворить наши потребности, и нам приходится использовать сервисный кластер, состоящий из нескольких машин.
В процессе предоставления услуг внешнему миру сервисный кластер может разложить вычислительную нагрузку, в определенной степени устранить узкое место в производительности и повысить доступность сервиса (сервис не будет недоступен из-за простоя одной машины ).
Итак, возникает вопрос:
(1) Работа программы часто зависит от многих файлов конфигурации, таких как адреса базы данных, управление черным списком, списки адресов служб и т. д., и некоторые данные конфигурации необходимо часто динамически изменять. все машины совместимы?
(2) Если одна машина умирает, как другие машины почувствуют это изменение и вступят во владение? Если есть всплеск пользователей и необходимо добавить больше машин, чтобы уменьшить нагрузку, как можно добавить машины без перезапуска кластера?
(3) Когда количество пользователей увеличивается или уменьшается, некоторые машины будут заняты использованием ресурсов, а другие будут бездействовать Как заставить каждую машину определять состояние загрузки других машин для достижения балансировки нагрузки?
(4) Относительно просто потребовать, чтобы несколько процессов или несколько потоков управляли одним и тем же ресурсом на одной машине, потому что может быть большой объем информации о состоянии или информации журнала для обеспечения гарантий.Например, когда два процесса A и B пишут файл в то же время, блокировка будет сделана. Но как насчет распределенных систем? Требуется трехсторонний механизм распределения блокировок Сотни рабочих записывают файлы в одной сети Как координировать? И как обеспечить эффективную работу?
2. Прошлое и настоящее ZooKeeper
Многие проблемы с распределенными системами вызваны отсутствием механизмов координации.
В настоящее время Chubby от Google и ZooKeeper от Apache лучше справляются с технологией распределенной координации. Некоторые люди спросят, зачем вам нужен ZooKeeper теперь, когда у вас есть Chubby, разве у Chubby дела идут плохо? Основная причина в том, что Chubby не имеет открытого исходного кода и используется самим Google. Позже Yahoo подражала Chubby и разработала ZooKeeper, который также реализовал аналогичную функцию распределенной блокировки, и передал ZooKeeper в качестве программы с открытым исходным кодом Apache, чтобы можно было использовать службу блокировки, предоставляемую ZooKeeper.
Что касается того, почему этот артефакт называется ZooKeeper, то это как-то связано с обычным юмористическим духом иностранцев. Как мы все знаем, иностранцы любят использовать животное в качестве талисмана, и ИТ-индустрия не является исключением. Например:
Hadoop, ответственный за работу с большими данными, — это желтый слон
3. Что такое зоопарк
С ростом популярности больших данных Hxx (согласно MapReduce, у нас есть Hadoop; согласно GFS, у нас есть HDFS; согласно BigTable, у нас есть HBase) стали привычными, и теперь, как разработчик, если вы не t Знание этих терминов заставляет вас стесняться приветствовать людей, когда вы выходите из дома.
Но на самом деле для нас, разработчиков, не занимающихся большими данными, Zookeeper — это базовый сервис, который может подвергаться воздействию не только Hxx. Однако беспомощно, что он молча расположился во второй строке и никогда не был таким ослепительным, как Hxx. Так что же такое Zookeeper? Для чего можно использовать Zookeeper? Как мы будем использовать Zookeeper? Как реализован Zookeeper?
К Zookeeper прилагаются два документа: один — Zab, в котором представлен протокол консенсуса, используемый в Zookeeper (протокол атомарной широковещательной рассылки Zookeeper), а другой — о самом Zookeeper. Zookeeper упоминается в обеих статьях как сервис для координации процессов распределенных приложений. Так что же такое служба распределенной координации? Сначала давайте посмотрим, что означает «координация».
Когда дело доходит до координации, первое, что приходит на ум, это координаторы движения на многих перекрестках в Пекине, которые держат маленькие красные флажки и сообщают, могут ли проехать автомобили и пешеходы. Если мы сравним транспортные средства и пешеходов с единицами (потоками), работающими в компьютере, что делает это совместное управление? Многие подумают, а не замок ли это? Да, в параллельной среде, чтобы избежать одновременного изменения общих данных несколькими работающими модулями, что приводит к повреждению данных, мы должны полагаться на механизм координации, такой как блокировки, чтобы одни потоки могли оперировать этими ресурсами сначала, а затем другие. темы ждут. Для внутрипроцессных блокировок различные языковые платформы, которые мы используем, подготовили множество вариантов. В случае с Java наиболее распространены синхронизированные методы или синхронизированные блоки:
public synchronized void sharedMethod(){
//对共享数据进行操作
}
После использования этого метода, когда несколько потоков работают с общим методом, шаги будут скоординированы, а ресурсы в общем методе не будут уничтожены, что приведет к несоответствиям.
Это самый простой метод координации, но иногда нам может понадобиться более сложная координация. Например, мы часто используем блокировки чтения-записи для повышения производительности. Поскольку большую часть времени мы больше читаем и меньше пишем в ресурсы, и если мы используем эксклюзивные блокировки записи независимо от того, используем ли мы их, это может повлиять на производительность. Или используйте java в качестве примера:
public class SharedSource{
private ReadWriteLock rwlock = new ReentrantReadWriteLock();
private Lock rlock = rwlock.readLock();
private Lock wlock = rwlock.writeLock();
public void read(){
rlock.lock();
try{
//读取资源
}finally{
rlock.unlock();
}
}
public void write(){
wlock.lock();
try{
//写资源
}finally{
wlock.unlock();
}
}
}
У нас также есть различные механизмы координации (обычно то, что мы называем механизмами синхронизации) внутри процесса. Теперь мы примерно понимаем, что такое координация, но описанная выше координация — это вся координация внутри процесса. Для координации внутри процесса мы можем использовать механизмы, предоставляемые нам языком, платформой, операционной системой и т. д. Так что, если мы находимся в распределенной среде? То есть наши программы работают на разных машинах, которые могут находиться в одной стойке, в одном компьютерном зале или в разных дата-центрах. В такой среде, что мы должны сделать для достижения координации? Вот чем занимается служба распределенной координации.
хорошо, некоторые люди могут сказать, что это не кажется трудным. Это не что иное, как реализация некоторых примитивов изначально в одном и том же процессе в распределенной среде через сеть. Да, на поверхности можно сказать. Но в распределенных системах зачастую легче сказать, чем сделать. В распределенной системе не существует всех предположений в рамках одного и того же процесса: потому что сеть ненадежна.
Например, в том же процессе, если ваш вызов метода успешен, это успех (конечно, если в вашем коде есть ошибка, это другое дело), если вызов не удался, например, выброшено исключение, звонок не проходит. В том же процессе, если этот метод вызывается первым, он выполняется первым. Но как насчет распределенной среды?
Из-за ненадежности сети ваш отказ от вызова службы не обязательно означает, что она не удалась.Возможно, что выполнение было выполнено успешно, но ответ потерпел неудачу, когда ответ был возвращен. Кроме того, и A, и B вызывают службу C. С точки зрения времени, A также вызывает сначала некоторые, а B звонит позже, поэтому окончательный результат должен заключаться в том, что запрос A поступает раньше B? Мы должны переосмыслить эти предположения, которые изначально были в одном и том же процессе, и нам также нужно подумать о том, как эти проблемы влияют на наш дизайн и кодирование. Кроме того, чтобы повысить надежность в распределенной среде, мы часто развертываем несколько наборов сервисов, но как добиться согласованности между несколькими наборами сервисов — это простая проблема, которую можно решить в рамках одного и того же процесса, но в распределенной среде. Действительно большая проблема. .
Таким образом, распределенная координация намного сложнее, чем координация в одном и том же процессе, поэтому появились базовые сервисы, такие как Zookeeper. Эти системы были опробованы и протестированы в различных системах, а их надежность и доступность подтверждены теорией и практикой. Поэтому, когда мы создаем некоторые распределенные системы, мы можем использовать такие системы в качестве отправной точки для создания наших систем, что сэкономит много средств и будет иметь меньше ошибок.
Вышеупомянутые попытки представить с периферии, что это за сервис Zookeeper и зачем он нам нужен. Далее я расскажу, что может сделать Zookeeper.
4. Что может Zookeeper
На официальном сайте Zookeeper есть предложение:ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
Это примерно описывает, что может сделать Zookeeper:配置管理,名字服务,分布式同步а также集群管理. Так что же это за услуги? Зачем нам такая услуга? Почему мы используем Zookeeper для достижения этой цели и каковы преимущества использования Zookeeper? Далее я расскажу, что это такое и какие системы с открытым исходным кодом используются.
-
Управление конфигурацией
В нашем приложении помимо кода есть еще и различные настройки. например соединения с базой данных. Как правило, мы используем файлы конфигурации, чтобы ввести эти файлы конфигурации в код. Когда у нас есть только одна конфигурация, один сервер и мы не изменяем его часто, рекомендуется использовать файл конфигурации, но если у нас много конфигураций, эта конфигурация нужна многим серверам, и она может быть динамической. файлы - не лучшая идея. В настоящее время нам часто нужно найти способ централизованного управления конфигурацией, мы модифицируем конфигурацию в этом централизованном месте, и все, кто заинтересован в этой конфигурации, могут получить изменения.Например, извлеките этот общий файл конфигурации и поместите его в одно место, и отслеживайте это место (узел каталога).Как только информация о конфигурации изменится, каждое приложение получит уведомление от Zookeeper, а затем получит новую информацию о конфигурации от Zookeeper. система. Однако, поскольку нормальная работа многих служб сильно зависит от этой конфигурации, служба, которая централизованно предоставляет службы конфигурации, должна быть очень надежной. Как правило, мы можем использовать кластер для предоставления этой службы настройки, но при использовании кластера для повышения надежности, как обеспечить согласованность конфигурации в кластере?
В настоящее время вам необходимо использовать службу, реализующую протокол консенсуса. Zookeeper — это такой сервис, который использует протокол консенсуса Zab для обеспечения согласованности. Многие проекты с открытым исходным кодом теперь используют Zookeeper для поддержки конфигурации.Например, в очереди сообщений с открытым исходным кодом Kafka Zookeeper также используется для хранения информации о брокере; в платформе SOA с открытым исходным кодом Dubbo от Alibaba Zookeeper также широко используется для управления некоторыми конфигурациями для достижения управление сервисом; В HBase клиент подключается к Zookeeper для получения необходимой информации о конфигурации кластера HBase перед дальнейшими операциями.
-
служба имен
Служба именования проста для понимания. Например, чтобы получить доступ к системе через сеть, мы должны знать IP-адрес другой стороны, но IP-адрес очень недружественный для людей.В настоящее время нам нужно использовать доменное имя для доступа. Но компьютер не распознает доменное имя. Как это сделать? Если у нас есть сопоставление доменного имени с IP-адресом на каждой машине, это может решить часть проблемы, но что, если IP-адрес, соответствующий доменному имени, изменится?Итак, у нас есть DNS. Нам достаточно посетить известную (известную) точку, она подскажет, какой IP соответствует данному доменному имени. В нашем приложении тоже много таких проблем, особенно когда у нас много сервисов, будет очень неудобно, если мы сохраняем адрес сервиса локально, а если нам нужно обращаться только к известной точке доступа, единой вход предусмотрен здесь, так что будет намного проще поддерживать.
Например, люди, которые использовали интегрированную систему Duboo+Zookeeper, также могут знать, что именно благодаря этому сервису именования облегчается связь между различными проектами в распределенной системе. (Remote Method Invoke) — это получение объекта на удаленном сервере через URL-адрес на определенном сервере для вызова службы, но в кластерной и распределенной среде, как сделать связь вызова между подпроектами не очень сложной , и не будет. Когда возникает проблема, мы не знаем, какой сервис какой называется, поэтому здесь нам нужен сервер, который бы управлял этими сервисами за нас, чтобы мы могли сконцентрироваться на бизнес-обработке. Функция именования Zookeeper является таким сервером. В кластере есть много провайдеров для одной и той же услуги. Когда эти провайдеры запускаются, соответствующая информация (интерфейс службы, адрес, порт и т. д.) провайдера регистрируется в Zookeeper. Когда потребитель хочет использовать услугу, Информационный каталог всех провайдеров сервиса получается в Zookeeper, а затем провайдер выбирается в соответствии с механизмом балансировки нагрузки Dubbo.
其实从配置管理、命名服务的作用中可以看出，Zookeeper相当于一个文件系统（类似与linux文件系统），换句话说，zookeeper是分布式中的大脑。 -
Распределенная блокировка
Распределенная блокировка, также известная как распределенная синхронизация. Например, упомянутый выше Zookeeper — это служба распределенной координации, поэтому мы можем использовать Zookeeper для координации действий между несколькими распределенными процессами.Например, в распределенной среде для повышения надежности один и тот же сервис развернут на каждом сервере в нашем кластере. Однако, если каждый сервер в кластере делает одно дело, им нужно координировать друг с другом, и это будет очень сложно запрограммировать. И если у нас есть только одна служба для работы, то есть одна точка. Обычно существует другой способ использования распределенных блокировок: в определенное время может работать только один сервис, при сбое которого блокировка снимается и сразу переключается на другой сервис.
Многие распределенные системы делают это, и у этой схемы есть лучшее название — «Выборы лидера». Например, мастер HBase использует этот механизм.
Однако следует отметить, что распределенные блокировки все же отличаются от блокировок в том же процессе, поэтому их используют более осторожно, чем блокировки в том же процессе.
-
Управление кластером
В распределенном кластере некоторые узлы часто входят и выходят из строя по разным причинам, таким как сбои оборудования, сбои программного обеспечения и проблемы с сетью. Новые узлы присоединяются, а старые узлы покидают кластер. В это время другие машины в кластере должны воспринять это изменение, а затем принять соответствующие решения на основе этого изменения.Например, в распределенной системе хранения есть центральный управляющий узел, отвечающий за распределение хранилища, и при поступлении нового хранилища нам необходимо выделить узлы хранения в соответствии с текущим состоянием кластера. В это время нам нужно динамически воспринимать текущее состояние кластера.
Кроме того, например, в распределенной архитектуре SOA услуги предоставляются кластером.Когда потребители обращаются к услуге, им необходимо использовать какой-либо механизм, чтобы обнаружить, какие узлы могут предоставлять услугу (это также называется обнаружением службы, например, открытый сервис Alibaba). исходный фреймворк SOA Dubbo использует Zookeeper в качестве базового механизма для обнаружения сервисов). Существуют также очереди Kafka с открытым исходным кодом, которые используют Zookeeper в качестве онлайн- и офлайн-управления Cosnumer.
Рекомендуемое чтение:
Справочная документация:
Один из ZooKeeper (1) Что такое ZooKeeper
Zookeeper -- Что такое Zookeeper?
Zookeeper - что может Zookeeper