В этой статье рассказывается о принципе Zookeeper. Редактор думает, что это довольно хорошо. Я поделюсь им с вами для вашего ссылки. Детали следующие:
Предисловие
Zookeeper - это распределенная координационная служба с открытым исходным координатом, созданную Yahoo, и является реализацией Google Chubby с открытым исходным кодом. Распределенные приложения могут реализовать такие функции, как публикация данных/подписка, балансировка нагрузки, службы именования, распределенная координация/уведомление, управление кластерами, магистерские выборы, распределенные блокировки и распределенные очереди на основе Zookeeper.
1. Введение
Zookeeper - это распределенная координационная служба с открытым исходным координатом, созданную Yahoo, и является реализацией Google Chubby с открытым исходным кодом. Распределенные приложения могут реализовать такие функции, как публикация данных/подписка, балансировка нагрузки, службы именования, распределенная координация/уведомление, управление кластерами, магистерские выборы, распределенные блокировки и распределенные очереди на основе Zookeeper.
2. Основные понятия
В этом разделе будут представлены несколько основных концепций Zookeeper. Эти концепции более подробно объясняются в более подробном отношении на Zookeeper, поэтому необходимо заранее понять эти концепции.
2.1 кластерные роли
В Zookeeper есть три персонажа:
Лидер
Последователь
Наблюдатель
В кластере Zookeeper будет только один лидер одновременно, а другие будут последователь или наблюдатель.
Конфигурация Zookeeper очень проста. Файл конфигурации (Zoo.cfg) каждого узла одинаков, и только файл myID отличается. Значение myID должно быть {numeric} частью сервера. {Numeric} в Zoo.cfg.
Пример содержимого файла Zoo.cfg:
Зокепер
Выполните статус зооуэпер-сервера на терминале машины с помощью Zookeeper. Вы можете увидеть, какую роль является зоопер текущего узла (лидер или последователь).
Зокепер
Как упоминалось выше, узел-20-104 является лидером, а узел-20-103 является последователем.
Zookeeper имеет только две роли: лидер и последователь по умолчанию, и нет роли наблюдателя. Чтобы использовать режим наблюдения, добавьте: Peertype = sticever в файл конфигурации любого узла, который хочет стать наблюдателем и добавить: Наблюдатель в строке конфигурации сервера, настроенной в режиме наблюдателя в файле конфигурации всех серверов, например:
server.1:localhost:2888:3888:observer
Все машины в кластере Zookeeper выбирают машину под названием «Лидер» в процессе выборов лидера. Сервер лидера предоставляет клиенту услуги чтения и записи.
Как последователь, так и наблюдатель могут предоставлять услуги чтения, но не писать услуги. Единственное различие между ними заключается в том, что машина наблюдателя не участвует в процессе выборов лидеров, и при этом она не участвует в «более половине успешной стратегии записи», поэтому наблюдатель может улучшить производительность чтения кластера, не влияя на производительность записи.
2.2 сеанс
Сессия относится к сеансу клиента. Прежде чем объяснить сеанс клиента, давайте впервые поймем подключение клиента. В Zookeeper клиентское соединение относится к длинному TCP -соединению между клиентом и сервером Zookeeper.
Сервисный порт по умолчанию Zookeeper составляет 2181. Когда клиент запускается, с сервером будет установлено соединение TCP. Начиная с первого учреждения соединения, также начинается жизненный цикл клиентской сессии. Благодаря этому соединению клиент может поддерживать действительный сеанс с сервером с помощью обнаружения HeartBeat, а также может отправлять запросы на сервер Zookeeper и принимать ответы. В то же время он также может получать уведомления о событиях наблюдения от сервера через это соединение.
Значение сеанса сеанса используется для установления времени ожидания клиентского сеанса. Когда клиентское соединение отключено из -за чрезмерного давления сервера, сбоя сети или активного отключения клиента, если сервер на кластере может быть повторно подключен в то время, указанное SessionTimeout, ранее созданный сеанс все еще действителен.
2.3 Узел данных (Znode)
При разговоре о распределенных, как правило, «узлы» относятся к каждой машине, которая образует кластер. Узел данных в Zookeeper относится к блоку данных в модели данных, называемой Znode. Zookeeper сохраняет все данные в памяти. Модель данных - это дерево (дерево Znode). Путь, деленная на черты (/), представляет собой Znode, такой как/hbase/Master, где Hbase и Master являются Znodes. Каждый Znode будет сохранять собственное содержание данных, и будет сохранена ряд атрибутов.
Примечание:
Znode здесь можно понимать как файл в UNIX и каталог в UNIX. Потому что каждый Znode может не только записывать данные сам (эквивалентно файлам в UNIX), но и иметь файлы или каталоги следующего уровня (эквивалентные каталогам в UNIX).
В Zookeeper Znode можно разделить на две категории: постоянные узлы и временные узлы.
Постоянный узел
Так называемый постоянный узел означает, что после создания этого Znode Znode будет сохранен на Zookeeper, если Znode не будет удален активно.
Временные узлы
Жизненный цикл временного узла связан с сеансом клиента. После того, как сеанс клиента не удастся, все временные узлы, созданные этим клиентом, будут удалены.
Кроме того, Zookeeper также позволяет пользователям добавлять специальный атрибут: последовательно для каждого узла. Как только узел помечен этим атрибутом, когда этот узел создается, Zookeeper автоматически добавит целочисленное число после его узла, которое является автоинчеркментальным номером, поддерживаемым родительским узлом.
Версия 2.4
Данные хранятся в каждом Znode of Zookeeper. Соответственно, Znode, Zookeeper сохраняет структуру данных, называемую STAT для него. Статируют три версии данных этого Znode, а именно версию (текущая версия Znode), Cversion (текущая версия Znode Child Node) и неприятие (текущая версия Znode ACL).
2.5 Информация о статусе
В дополнение к хранению содержания данных, каждый Znode также хранит некоторую информацию о статусе самого Znode. Используйте команду GET, чтобы одновременно получить информацию о контенте и статусе определенного Znode. следующее:
Зокепер
В Zookeeper атрибут версии используется для реализации «проверки записи» в механизме оптимистического блокировки (для обеспечения атомной работы распределенных данных).
2.6 операция транзакции
В Zookeeper операция, которая может изменить состояние сервера Zookeeper, называется операцией транзакции. Как правило, он включает в себя такие операции, как создание и удаление узлов данных, обновление содержания данных, создание и сбой сессии клиента. Для каждого запроса транзакции Zookeeper назначит ему глобально уникальный идентификатор транзакции, представленную ZXID, обычно 64-разрядным номером. Каждый ZXID соответствует операции обновления, из которой Zookeeper может косвенно идентифицировать глобальный порядок, в котором обрабатываются эти запросы на операцию транзакции.
2.7 Наблюдатель
Watcher (Event Serialer) - очень важная функция в Zookeeper. Zookeeper позволяет пользователям зарегистрировать некоторые наблюдатели на указанных узлах, и когда некоторые конкретные события запускаются, сервер Zookeeper уведомит событие заинтересованному клиенту. Этот механизм является важной особенностью Zookeeper для внедрения распределенных координационных услуг.
2,8 ACL
Zookeeper использует политику ACL (списки контроля доступа) для контроля разрешений. Zookeeper определяет следующие 5 разрешений.
Создать: разрешение на создание дочерних узлов.
Читать: Получите разрешения для узлов данных и списка детских узлов.
Напишите: разрешение на обновление данных узла.
Удалить: удалить разрешения детских узлов.
Администратор: установить разрешения для узла ACL.
Примечание. Создание и удаление являются контроль разрешения для дочерних узлов.
3. Типичные сценарии применения Zookeeper
Zookeeper - это очень доступная распределенная структура управления данными и координации. Основываясь на реализации алгоритма ZAB, эта структура может обеспечить согласованность данных в распределенной среде. Он также основан на этой функции, которая делает Zookeeper мощным инструментом для решения проблемы распределенной последовательности.
3.1 Публикация и подписка данных (Центр конфигурации)
Публикация данных и подписка, так называемый центр конфигурации, как следует из названия, заключается в том, что издатель публикует данные в узле Zookeeper для подписчиков для данных, тем самым достигая цели динамического получения данных и реализации централизованного управления и динамического обновления информации о конфигурации.
В нашей обычной разработке системы приложений мы часто сталкиваемся с этим требованием: в системе необходима некоторая общая информация о конфигурации, такую как информация о списке машин, информация о конфигурации базы данных и т. Д. Эта глобальная информация о конфигурации обычно имеет следующие три функции.
Количество данных обычно относительно невелико.
Содержание данных динамически изменяется во время выполнения.
Все машины в кластере являются общими, а конфигурация согласована.
Такая глобальная информация о конфигурации может быть опубликована на Zookeeper, что позволяет клиенту (кластерная машина) подписаться на сообщение.
Как правило, существует два режима проектирования для издательских/подписных систем, а именно толкание и вытягивание.
Push: сервер активно отправляет обновления данных всем подписанным клиентам.
PULL: Клиент активно инициирует запрос на получение последних данных. Обычно клиент принимает метод избирательного участка и вытягивания.
Zookeeper использует комбинацию толчка и тяги. следующее:
Клиент хочет, чтобы сервер зарегистрировал узлы, на которые ему необходимо обратить внимание. После изменения данных узла сервер отправит уведомление о событии наблюдателя соответствующему клиенту. После того, как клиент получает это уведомление об этом сообщении, ему необходимо активно перейти на сервер, чтобы получить последние данные (в сочетании с Push и Pull).
3.2 Служба именования
Услуги именования также являются общим сценарием в распределенных системах. В распределенной системе, используя службу именования, клиентские приложения могут получать информацию, такую как адрес ресурса или услуги, поставщик и т. Д. На основе указанного имени. Названные объекты обычно могут быть машинами в кластере, предоставляемых услугах, удаленными объектами и т. Д. - мы можем коллективно назвать их именами (имя).
Среди них наиболее распространенным является список адресов обслуживания в некоторых распределенных фреймворках (например, RPC, RMI). Создавая последовательные узлы в ZookeePR, легко создать глобально уникальный путь, который можно использовать в качестве имени.
Служба именования Zookeeper генерирует глобально уникальный идентификатор.
3.3 Распределенная координация/уведомление
Zookeeper имеет уникальную регистрацию наблюдателя и механизм асинхронного уведомления, который может хорошо реализовать уведомление и координацию между различными машинами и даже различными системами в распределенной среде, тем самым реализуя обработку изменений данных в реальном времени. Метод использования, как правило, состоит в том, что разные клиенты регистрируют один и тот же Znode на ZK, чтобы прослушать изменения в Znode (включая содержание самого Znode и детских узлов). Если Znode изменяется, все подписанные клиенты могут получить соответствующее уведомление о наблюдателе и сделать соответствующую обработку.
Распределенная координация/уведомление ZK является общим способом связи между распределенными системами и машинами.
3.3.1 Обнаружение сердцебиения
Механизм обнаружения сердцебиения между машинами означает, что в распределенной среде различные машины (или процессы) должны определить, работают ли друг друга нормально. Например, машина A должна знать, работает ли Machine B нормально. В традиционном развитии мы обычно судим, может ли хозяин непосредственно пинг друг друга. Если это сложнее, мы установим длительную связь между машинами и осознаем обнаружение сердцебиения машин верхнего уровня посредством внутреннего механизма обнаружения сердцебиения соединения TCP. Это очень распространенные методы обнаружения сердцебиения.
Давайте посмотрим, как использовать ZK для реализации обнаружения сердцебиения между распределенными машинами (процессами).
Основываясь на характеристиках временных узлов ZK, различные процессы могут создавать временные дочерние узлы под указанным узлом в ZK. Различные процессы могут непосредственно судить, является ли соответствующий процесс живым на основе этого временного детского узла. Таким образом, обнаружение и обнаруженная система не должны быть непосредственно связаны, но связаны с определенным узлом на ZK, что значительно уменьшает связь системы.
3.3.2 Отчет о выполнении работы
В общей системе распределения задач, обычно после того, как задача распределяется на различные машины для выполнения, необходимо сообщить о прогрессе выполнения задачи в систему распределения в режиме реального времени. На этот раз это может быть достигнуто через ZK. Выберите узел на ZK, и каждый клиент задачи создает временные дочерние узлы под этим узлом, чтобы быть достигнуты две функции:
Определите, выживает ли задача, судя о том, существует ли временный узел.
Каждая задача записывает выполнение выполнения задачи в этот временный узел в режиме реального времени, чтобы центральная система могла получить прогресс выполнения задачи в режиме реального времени.
3.4 Мастер -выборы
Можно сказать, что магистерские выборы являются наиболее типичным сценарием применения Zookeeper. Например, выборы активного наменода в HDF, выборы активного ресурсанажера в пряже и выборы активного HMaster в HBASE.
В ответ на потребности главных выборов мы обычно можем выбрать основную ключевую функцию в общих реляционных базах данных для реализации: если машины, которые становятся мастерами, вставляют запись одного идентификатора первичного ключа в базу данных, база данных поможет нам выполнить проверки конфликтов первичного ключа, то есть только одна машина может успешно внедрить, тогда мы думаем, что клиентская машина, которая успешно внедряет данные в данные, становится камерой.
Опираясь на первичные ключевые характеристики реляционных баз данных, действительно может гарантировать, что единственный мастер избирается в кластере.
Но что мне делать, если избранный в настоящее время магистр мертв? Кто скажет мне, что Мастер мертв? Очевидно, что реляционная база данных не может уведомить нас об этом событии. Но Zookeeper может сделать это!
Использование сильной согласованности Zookeepr может гарантировать, что создание узлов может обеспечить глобальную уникальность в распределенной высокой параллелистике, то есть Zookeeper гарантирует, что клиент не может создать существующий Znode.
То есть, если несколько клиентов запрашивают одновременно создать один и тот же временный узел, то в конце концов может быть успешно создан только один запрос клиента. Используя эту функцию, мастер -выборы могут быть легко выполнены в распределенной среде.
Машина, где находится клиент, который успешно создал узел, становится мастером. В то же время другие клиенты, которые не успешно создали узел, зарегистрируют наблюдатель за изменением узла детского узла, чтобы контролировать, живой ли текущий мастер -машина. После того, как нынешний мастер будет обнаружен мертвым, другие клиенты будут переизбраны.
Это позволяет динамическим выборам мастера.
3.5 Распределенный замк
Распределенные замки - это способ контролировать синхронный доступ к общим ресурсам между распределенными системами.
Распределенные замки делятся на эксклюзивные замки и общие замки.
3.5.1 Эксклюзивный замок
Эксклюзивные блокировки (x блокировки для короткости), также известные как блокировки записи или эксклюзивные блокировки.
Если транзакция T1 добавляет эксклюзивную блокировку к объекту данных O1, то в течение всего периода блокировки только транзакция T1 разрешена читать и обновить O1, и никакая другая транзакция не может выполнять какую -либо тип операции на этом объекте данных (объект не может быть заблокирован), пока T1 не выпустит исключительную блокировку.
Можно видеть, что ядро эксклюзивного блокировки заключается в том, как гарантировать, что только одна транзакция в настоящее время приобретает блокировку, и после того, как замок будет выпущен, все транзакции, ожидающие приобретения блокировки, могут быть уведомлены.
Как использовать Zookeeper для достижения эксклюзивной блокировки?
Определите блокировку
Znode на Zookeeper может представлять блокировку. Например, узлом /exclusive_lock /lock может быть определен как блокировка.
Получите замок
Как упомянуто выше, рассмотрите Znode на Zookeeper как блокировку, и получение блокировки достигается путем создания Znode. Все клиенты перейдут в /exkwact_lock /lock, чтобы создать временные дочерние узлы /exclusive_lock /lock ind /exclusive_lock. Zookeeper гарантирует, что среди всех клиентов может быть успешно создано только один клиент, и тогда можно считать, что клиент получил блокировку. В то же время всем клиентам, которые не получили блокировку, должны зарегистрировать наблюдатель за изменениями узел детского узла на узле /exclusive_lock, чтобы прослушать изменения узла блокировки в режиме реального времени.
Отпустите замок
Поскольку /exclusive_lock /lock является временным узлом, можно отпустить блокировку в обоих случаях.
Если клиентская машина в настоящее время получает сбой или перезагрузку блокировки, временный узел будет удален и будет выпущен замок.
После того, как бизнес -логика будет выполнена нормально, клиент будет активно удалять созданный он созданный узел и отпустить блокировку.
Независимо от того, при каких обстоятельствах узел блокировки удаляется, Zookeeper уведомляет всех клиентов, у которых зарегистрировали наблюдатель за изменением узла, прослушивание на узле /exclusive_lock. После получения уведомления эти клиенты снова повторно инициируют распределенное приобретение блокировки, то есть повторяя «приобретение замков».
3.5.2 Общий замок
Общие блокировки (S Locks, называемые S Locks), также известные как блокировки чтения. Если транзакция T1 добавляет общую блокировку в объект данных O1, то T1 может читать только O1, а другие транзакции также могут добавить общий блокировку в O1 одновременно (не эксклюзивный блокировка). O1 может быть добавлен только в эксклюзивный замок, пока не будут выпущены все общие замки на O1.
Резюме: Несколько транзакций могут получить общую блокировку для объекта одновременно (одновременно прочитанное). Если есть общая блокировка, вы не можете добавить эксклюзивную блокировку (потому что эксклюзивная блокировка является блокировкой записи)
4. Применение Zookeeper в крупных распределенных системах
Типичные сценарии применения Zookeeper были представлены ранее. В этом разделе будет представлена применение Zookeeper в общих продуктах больших данных Hadoop и Hbase в качестве примеров, которые помогут всем лучше понять распределенные сценарии применения Zookeeper.
4.1 Применение Zookeeper в Hadoop
В Hadoop Zookeeper в основном используется для реализации HA (доступность HIVE), включая HDFS Namanode и HA ResourceManager's HA. В то же время, в пряже, ZookeePR также используется для хранения рабочего состояния приложения.
Принцип использования ZookeePR для реализации HA одинаков в ресурсагере Namanode и Yarn's ResourceManager от HDFS, поэтому в этом разделе вводит ее с пряжей.
Зокепер
Как видно из приведенного выше рисунка, пряжа в основном состоит из четырех частей: ресурс -манагер (RM), Nodemanager (NM), ApplicationMaster (AM) и контейнер. Самым основным из них является ресурс.
ResourceManager отвечает за единое управление и распределение всех ресурсов в кластере. Он также получает информацию о отчетности по ресурсам от каждого узла (Nodemanager) и выделяет эту информацию каждому приложению (диспетчер приложения) в соответствии с определенными политиками. Он поддерживает информацию о приложении, информации о Nodemanager и использовании ресурсов каждого приложения.
Чтобы реализовать HA, несколько ресурсов должны сосуществовать (обычно два), и только один ресурс -манагер находится в активном состоянии, в то время как другие находятся в состоянии резервного режима. Когда активный узел не может работать должным образом (например, простоя машины или перезапуск), резерв будет конкурировать, чтобы генерировать новый активный узел.
4.2 Основной и резервный переключатель
Давайте посмотрим, как пряжа реализует переключение мастер-субсидий между несколькими ресурсами.
1. Создайте узел блокировки. На Zookeeper будет a /jars-leader-letaction /appcluster-y-hock-узло. Когда все ресурсы будут запущены, они будут конкурировать, чтобы написать узел для детей:/лидер-лидер-лидер/Appcluster-Yarn/ActiveBreadcrumb. Этот узел - временный узел.
Zookeepr может гарантировать, что в конце концов может быть создан только один ресурс -манагер. Ресурс, который был успешно создан, будет переключен на активное состояние, в то время как те, которые не были успешными, будут переключены на состояние резервного режима.
Зокепер
Вы можете видеть, что ResourceManager2 в кластере активен в настоящее время.
Зарегистрировать наблюдатель
Все ресурсы в государственных штатах зарегистрируют наблюдателя за изменением узла на я пряжу лидер-выборы/Appcluster-Yarn/ActiveBreadcrumb Node. Используя характеристики временных узлов, вы можете быстро ощутить работу ресурсов в активных состояниях.
Основной и резервный переключатель
Когда ресурс активного состояния испытывает исключение, такое как время простоя или перезапуск, сеанс клиента, подключенный к Zookeeper, будет недействительным, поэтому будет удален узлом/Appcluster-Yarn/ActiveBreadcrumb. В настоящее время другие ресурсы в статусе резервного режима получат уведомление о событии наблюдателя от сервера Zookeeper, а затем повторят работу шага 1.
Выше приведено процесс использования Zookeeper для реализации основного и резервного переключения ресурсов, который реализует HA ResourceManager.
Принцип реализации Namenode HA в HDFS совпадает с принципом реализации ресурсанателя HA в пряже. Его узел блокировки/Hadoop-Ha/MyCluster/ActiveBreadCrumb.
4.3 Статусное хранилище ResourceManager
В ResourceManager RMStatestore может хранить некоторую внутреннюю информацию о RM, включая приложение и их попытки информации, токены делегирования, информацию о версиях и т. Д. Следует отметить, что большинство государственных информации в RMStatestore не нужно сохранять хранение, поскольку легко реконструировать ее из контекстной информации, такой как ресурсное использование. В схеме проектирования хранения предоставляется три возможных реализации, соответственно, следующим образом.
Основываясь на реализации памяти, она обычно используется для ежедневной разработки и тестирования.
Реализации на основе файловой системы, такие как HDFS.
На основе реализации Zookeeper.
Поскольку объем данных этой информации о состоянии не очень велик, Hadoop официально рекомендует реализовать хранение информации о государственной информации на основе Zookeeper. В Zookeepr информация о состоянии ресурсанажера хранится под корневым узлом /rmstore.
Зокепер
Узел RMAppoot хранит информацию, связанную с каждым приложением, а RMDTSecretManagerRoot хранит информацию, связанную с безопасностью и другой информацией. Resourcemanager каждого активного состояния читает эту информацию о состоянии от Zookeeper на этапе инициализации и продолжает обрабатывать соответствующую на основе этой информации о статусе.
4.4 Резюме:
Основными приложениями Zookeepr в Hadoop являются:
HA of Namenode в HDFS и HA ресурсанажера в пряже.
Хранить информацию о статусе RMStatestore
5. Применение Zookeeper в Hbase
HBASE в основном использует Zookeeper для реализации выборов HMAST
Управление задачами Splitwal и т. Д.
5.1 Выборы Hmaster и основной резервный выключатель
Принцип выборов Hmaster и переключения магистерской поддержки совпадает с принципом HA Namenode в HDF и ресурсах в пряже.
5.2 Системная допуск ошибок
Когда HBASE запускается, каждый регион -сервер будет создавать информационный узел в узле/hbase/rs Zookeeper (далее мы называем этот узел «Узел состояния RS»), такой как/hbase/rs/[hostname]. В то же время Hmaster зарегистрируется и прослушивает этот узел. Когда регион стерт, Zookeeper удалит узел статуса RS, соответствующий серверу регионов, поскольку он не может принять свое сердцебиение в течение определенного периода времени (то есть сеанс недействителен).
В то же время Hmaster получит уведомление Nodedelete от Zookeeper, таким образом, ощущение узела отключается и немедленно запускает отказоустойчивую работу.
Почему Hbase не позволяет Hmaster нести ответственность за мониторинг регионов? Если Hmaster непосредственно управляет статусом регионов через механизмы сердцебиения, поскольку кластер становится больше и больше, управляющее бремя Hmaster станет более тяжелым, и это также может потерпеть неудачу, поэтому данные необходимо сохранять. В этом случае Zookeeper становится идеальным выбором.
5.3 Управление корней
Для кластеров HBASE информация о местоположении хранилища данных записывается в области метаданных, то есть корневион. Каждый раз, когда клиент инициирует новый запрос и должен знать местоположение данных, он будет запрашивать корнерегион, а собственное местоположение RootRegion записывается на Zookeeper (по умолчанию он записан в узле Zookeeper /Hbase /Meta-Region-Server).
Когда изменяется корнеру, например, ручное движение региона, перезагрузка балансировки или отказ сервера корневирования, он может ощутить это изменение через Zookeeper и принять серию соответствующих мер аварийного восстановления, чтобы убедиться, что клиент всегда может получить правильную информацию об корнерете.
5.4 Управление регионом
Регионы в HBASE часто меняются. Причинами этих изменений являются сбои системы, балансировка нагрузки, модификация конфигурации, разделение и слияние области и т. Д. Как только регион перемещается, он проходит через процесс офлайн и онлайн.
Данные не могут быть доступны во время офлайн, и это изменение в регионе должно быть известно на глобальном уровне, в противном случае могут произойти транзакционные исключения.
Для крупных кластеров Hbase количество регионов может достигать 100 000 или даже больше. Это также хороший выбор, чтобы покинуть управление государством региона в таком масштабе в Zookeeper.
5.5 Распределенное управление задачами Splitwal
Когда сервер регионов вешает трубку, поскольку всегда есть часть недавно написанных данных, которые не были удержаны в HFILE, при миграции службы регионов, важной задачей является восстановление этой части данных, которые все еще находятся в памяти из WAL. Наиболее важным шагом в этой части работы является раздел, то есть Hmaster должен пройти через WAL на сервере регионов, разделить его на небольшие кусочки и переместить его на новый адрес и воспроизводить журнал.
Поскольку объем журнала одного региона является относительно великим (могут быть тысячи регионов, с GB журналов), пользователи часто надеются, что система сможет быстро завершить работу по восстановлению журнала. Следовательно, выполнимое решение состоит в том, чтобы выделить эту задачу, которая обрабатывает WAL с несколькими серверами регионов для совместной обработки, что требует постоянного компонента для оказания помощи Hmaster в выполнении распределения задач.
Текущая практика заключается в том, что Hmaster создаст узел Splitwal на Zookeeper (по умолчанию, это /hbase /splitwal -узел), хранит информацию, такую как «какой регионов обрабатывает, какой регион« в узле в списке, а затем каждый сервер регионов будет перейти к узлу, чтобы собрать задачу и обновить информацию о задачи после того, как задача выполняет успешное, чтобы не продолжить. Zookeeper играет роль взаимного уведомления и настойчивости информации в распределенных кластерах здесь.
5.6 Резюме:
Выше приведены некоторые типичные сценарии в Hbase, которые полагаются на Zookeeper для выполнения распределенных координационных функций. Но на самом деле, HBASE имеет больше, чем такая зависимость от зооуэклара. Например, Hmaster также полагается на Zookeeper для завершения записи о включении/отключении статуса таблицы, и почти все хранилище метаданных в hBase помещаются в зоопер.
Из -за превосходных распределенных координационных возможностей Zookeeper и механизма хорошего уведомления HBASE все чаще добавляют сценарии применения ZooKeeper в эволюции каждой версии, и с точки зрения тенденции у них все больше и больше пересечений. Все операции на Zookeeper в Hbase инкапсулируются в пакете org.apache.hadoop.hbase.zookeeper. Заинтересованные студенты могут изучать это сами.
Выше приведено модуль Spring Boot, который вам представил редактор. Я надеюсь, что это будет полезно для вас. Если у вас есть какие -либо вопросы, пожалуйста, оставьте мне сообщение, и редактор ответит вам вовремя!