Zookeeper — это подпроект Hadoop, и хотя он основан на Hadoop, я заметил, что Zookeeper всё чаще использует распределённые фреймворки вне Hadoop. Сегодня я хочу поговорить о Zookeeper, в этой статье я не буду говорить о том, как использовать Zookeeper, а о его практических применениях, о том, какие типы приложений могут использовать преимущества Zookeeper, и, наконец, о том, какую роль Zookeeper может играть в распределённой архитектуре сайтов.
Zookeeper — это высоконадежная система координации для больших распределённых систем. Из этого определения мы знаем, что Zookeeper — это скоординированная система, действующая на распределённых системах. Зачем распределённым системам нужна система координации? Причины следующие:
Разработка распределённой системы — очень сложная задача, и её сложность в основном отражается в «частичном отказе» распределённой системы. «Частичный отказ» означает передачу информации между двумя узлами сети: если сеть выходит из строя, отправитель не может знать, получил ли получатель сообщение, и причина этого сбоя сложна: получатель мог получить сообщение или не получить до ошибки сети, либо процесс получателя был мертв. Единственный способ отправителю получить реальную картину — это переподключиться к приемнику и спросить у получателя, почему произошла ошибка, которая и есть проблема «частичного отказа» в распределённой системе.
Zookeeper — это фреймворк для решения проблемы «частичного отказа» распределённых систем. Zookeeper не позволяет распределённым системам избегать проблем с «частичными отказами», но позволяет распределённым системам правильно справляться с такими проблемами при возникновении частичных отказов, чтобы распределённые системы могли работать нормально.
Давайте поговорим о практическом применении Zookeeper:
Сценарий 1: Существует группа серверов, которые предоставляют определённый сервис клиенту (например, серверная сторона распределённого сайта, который я создал ранее, представляет собой кластер из четырёх серверов для предоставления услуг фронтенд-кластеру), и мы надеемся, что клиент сможет найти сервер в кластере серверов каждый раз, когда запросит его, чтобы сервер мог предоставить клиенту необходимые сервисы. В этом случае нам нужен список серверов в нашей программе, из которого мы читаем список серверов каждый раз, когда клиент его запрашивает. Тогда этот подсписок, очевидно, нельзя хранить на одном сервере узла, иначе узел отключится, и весь кластер выйдет из строя, и мы надеемся, что этот список будет очень доступен в этот момент. Если сервер в списке хранилища сломан, другие серверы могут немедленно заменить сломанный сервер, и сломанный сервер может быть удалён из списка, чтобы неисправный сервер мог отключиться из работы всего кластера, и все эти операции будут выполняться не неисправным сервером, а обычным сервером в кластере. Это активная распределённая структура данных, которая может активно изменять состояние элементов данных при изменении внешних условий. Фреймворк Zookeeper предоставляет эту услугу. Название этого сервиса: Unified Naming Service, который очень похож на сервис JNDI в javaEE.
Сценарий 2: Распределённый сервис замков. Когда распределённая система манипулирует данными, например, читает данные, анализирует и, наконец, изменяет данные. В распределённой системе эти операции могут быть распределены между разными узлами кластера, тогда возникает проблема согласованности в процессе работы с данными, если она несогласована, мы получим неправильный результат операции, в одной программе процесса задача согласованности легко решить, но сложнее достичь распределённой системы, поскольку операции разных серверов в распределённой системе происходят в независимых процессах, а промежуточные результаты и процессы операции должны передаваться по сети. Тогда гораздо сложнее добиться согласованности с данными. Zookeeper предоставляет сервис блокировки, который решает эту проблему, позволяя нам обеспечивать согласованность операций с данными при выполнении распределённых операций.
Сценарий 3: Управление конфигурацией. В распределённой системе мы разворачиваем сервисное приложение на n серверах отдельно, и конфигурационные файлы этих серверов одинаковы (например, в распределённом веб-фреймворке, который я разработал, на серверной стороне 4 сервера, программы на 4 серверах одинаковые, и конфигурационные файлы одинаковы), если настройки конфигурационных файлов меняются, то их нужно менять по одному, если нужно менять серверы, эти операции не слишком хлопотные, Если у нас большое количество распределённых серверов, например, кластер Hadoop крупной интернет-компании с тысячами серверов, то изменение конфигураций может быть сложной и опасной. В данный момент zookeeper может пригодиться: мы можем использовать zookeeper как высокодоступную конфигурационную память, передать её Zookeeper для управления, мы скопируем конфигурационный файл кластера в узел файловой системы Zookeeper, а затем с помощью Zookeeper отслеживаем статус конфигурационного файла во всех распределённых системах, когда выясняется, что конфигурационный файл изменился, Каждый сервер получает уведомление от Zookeeper о синхронизации конфигурационных файлов в Zookeeper, а сервис Zookeeper также гарантирует, что операция синхронизации является атомарной для правильного обновления конфигурационного файла каждого сервера.
Сценарий 4: Обеспечение функций устранения неисправностей для распределённых систем. Управление кластером сложно, и добавление сервиса Zookeeper в распределённую систему облегчает нам управление кластером. Самое сложное в управлении кластером — это управление неисправностями узлов: Zookeeper может позволить кластеру выбрать здоровый узел в качестве мастера, мастер-узел будет знать текущее состояние состояния каждого сервера в кластере; после отказа мастер уведомляет остальные серверы кластера, чтобы перераспределить вычислительные задачи разных узлов. Zookeeper может не только найти неисправности, но и проверить неисправный сервер, определить, какой тип неисправности он является, если неисправность удаётся устранить, Zookeeper может автоматически исправить или сообщить системному администратору причину ошибки, чтобы администратор мог быстро найти проблему и устранить неисправность узла. Возможно, у вас всё ещё есть вопрос: что делать, если главный клапан неисправен? Zookeeper также учитывает это: у Zookeeper есть внутренний «алгоритм выбора лидеров», мастеров можно динамически выбирать, и если мастер не справляется, Zookeeper может сразу выбрать нового мастера для управления кластером.
Давайте поговорим о функциях Zookeeper:
ZooKeeper — это упрощённая файловая система. Это немного похоже на Hadoop, но файловая система ZooKeeper управляет мелкими файлами, а Hadoop — очень большими.
Zookeeper предоставляет множество «артефактов», которые позволяют многим операциям координировать структуры данных и протоколы. Например: распределённые очереди, распределённые блокировки и алгоритм «выбора лидера» группы узлов на одном уровне.
ZooKeeper очень доступен, его собственная стабильность довольно хороша, распределённые кластеры могут полагаться на управление кластерами Zookeeper, а ZooKeeper используется для предотвращения проблемы одноточкового отказа распределённых систем.
В Zookeeper используется слабо связанный режим взаимодействия. Это особенно заметно в том, что Zookeeper предоставляет распределённые замки, которые могут использоваться как механизм назначения, позволяющий участвующим процессам обнаруживать и взаимодействовать друг с другом, не зная других процессов (или сети), и участвующие участники даже не обязаны существовать одновременно, если они оставляют сообщение в Zookeeper, и после завершения процесса другой процесс может прочитать это сообщение, тем самым разрушая связь между узлами.
ZooKeeper предоставляет общий репозиторий для кластера, из которого кластер может централизованно читать и записывать общую информацию, избегая программирования общих операций для каждого узла и снижая сложность разработки распределённых систем.
Zookeeper в основном отвечает за хранение и управление теми данными, которые важны для всех, а затем принимает регистрацию наблюдателей; после изменения статуса данных он будет уведомлять тех наблюдателей, зарегистрировавшихся на Zookeeper, чтобы они реагировали соответствующим образом, чтобы достичь режима управления мастер/слейв, аналогичного кластеру.
Видно, что Zookeeper очень способствует разработке распределённых систем, что делает распределённые системы более надёжными и эффективными.
Недавно я участвовал в группе по интересам Hadoop в отделе, установил Hadoop, Mapreduce, Hive и Hbase в тестовой среде, а также заранее установил Zookeeper при установке hbase. Zookeeper может предоставлять услуги, так что более половины из 3 — это 2, а более половины из 4 — это тоже два, поэтому установка трёх серверов может получить эффект 4 серверов. В процессе изучения Hadoop я считаю, что Zookeeper — самый сложный подпроект для понимания, причина не в технической ответственности, а в том, что направление его применения для меня очень запутанно, поэтому моя первая статья о технологии Hadoop начинается с Zookeeper и не касается конкретной технической реализации, но из примеров применения Zookeeper я понимаю сферу применения Zookeeper, думаю, что изучение Zookeeper будет эффективнее с половиной меньших усилий.
Причина, по которой я хочу сегодня поговорить о Zookeeper, — это дополнение к фреймворку распределённого сайта, описанного в моей предыдущей статье. Хотя я спроектировал архитектуру сайта как распределённую структуру, я также создал простой механизм обработки сбоев, например, механизм сердечного ритма, но всё равно невозможно решить единственную точку отказа кластера: если сервер сломан, клиент попытается подключиться к нему, что приведёт к блокировке некоторых запросов и к потере ресурсов сервера. Однако сейчас я не хочу менять свой фреймворк, потому что всегда считаю, что добавление сервиса Zookeeper к существующим сервисам повлияет на эффективность сайта. К счастью, наш отдел также столкнулся с такой проблемой: мы разработаем мощную систему удалённых звонков, разделят управление кластером и коммуникацию и централизованно предоставят эффективные и доступные услуги.
Переведён из ttp://www.cnblogs.com/sharpxiajun/archive/2013/06/02/3113923.html |
Опубликовано 18.07.2017 14:19:01
|
|
|
