ZooKeeper

давно не видела тебя

Прошел почти месяц с момента публикации последней статьи, и я думаю, что прошел почти месяц с тех пор, как я ничего не писал.. Могут быть выпускные экзамены, разработка учебного плана и экзамены на водительские права, но это не оправдание!

Зимой лениться не могу, надеюсь огромное количество экскаваторов меня подстегнет 🙄🙄✍️✍️.

Статья очень длинная, сначала поставьте лайк, а потом прочтите, чтобы вошло в привычку. ❤️ 🧡 💛 💚 💙 💜

Что такое ZooKeeper?

ZooKeeperЗависит отYahooразработан, а затем передан в дарApache, который теперь сталApacheВерхний пункт.ZooKeeperЭто сервер координации распределенных приложений с открытым исходным кодом, который предоставляет согласованные услуги для распределенных систем. Его целостность основана наPaxosалгоритмическийZABСоглашение завершено. К его основным функциям относятся: обслуживание конфигурации, распределенная синхронизация, управление кластером, распределенные транзакции и т. д.

Проще говоря,ZooKeeperЯвляетсяПлатформа службы распределенной координации. распределяется? Координационная служба? Что это, черт подери, такое? 🤔🤔

На самом деле, объясняя концепцию распределения, я обнаружил, что некоторые студенты не очень хорошо понимают две концепции **распределения и кластера**. Некоторое время назад мы с одноклассником обсуждали распределённые вещи, он сказал, что распределённое — это не просто сложение машин? Одной машины недостаточно, добавьте еще одну, чтобы противостоять давлению. Конечно, в добавлении машин нет ничего плохого, ваша распределенная система должна включать несколько машин, но не забывайте, что в информатике есть похожее понятие —Cluster, Разве кластер не добавляет машины? Но кластеризация и распределение — это на самом деле два совершенно разных понятия.

Например, теперь у меня есть служба seckill, и параллелизм слишком велик для системы с одной машиной, поэтому я могу добавить несколько серверов.Такой жеОбеспечьте пиковый сервис, на этот разClusterкластер.

Тем не менее, я сейчас изменю путь, я буду обслуживать шипРазделить на несколько подсервисов, такие как создание сервисов заказов, добавление сервисов баллов, вычет сервисов купонов и т. д.,Затем я развертываю все эти подсервисы на разных серверах., это времяDistributedраспределенный.

И почему я опровергаю то, что мои одноклассники говорили, что дистрибутив - это сложение машин? Потому что я думаю, что добавление машин больше подходит для создания кластеров, потому что на самом деле это просто добавление машин. Для распределенного сначала нужно разделить бизнес, а затем добавить машины (не просто добавление машин), и в то же время вы должны решить ряд проблем, вызванных распределением.

Например, как координировать различные распределенные компоненты, как уменьшить связь между различными системами, как обрабатывать распределенные транзакции, как настроить всю распределенную систему и так далее.ZooKeeperВ основном для решения этих проблем.

Проблемы согласованности

Проектирование распределенной системы обязательно столкнется с проблемой -Из-за существования толерантности к разделам (толерантности к разделам) мы должны найти компромисс между доступностью системы (доступностью) и согласованностью данных (непротиворечивостью).. это известноCAPтеорема.

На самом деле это очень просто понять, например, класс рассматривается как единая система, а ученики являются самостоятельными подсистемами в системе. В это время Сяохун Сяомин в классе была тайно влюблена и была обнаружена Сяохуа, которая была болтуном в классе.Сяохуа была в восторге и рассказала окружающим, а затем новость об отношениях Сяохун Сяомин распространилась по классу. . В процессе рассылки новостей (раздачи) вы ловите одноклассника и спрашиваете его об их положении.Если вы не знаете ответа, значит, есть проблема несогласованности данных во всей системе классов (потому что Сяохуа уже знает Новости). И если он не отвечает вам напрямую, потому что новость распространяется по всему классу (чтобы обеспечить согласованность, все должны знать, чтобы оказывать услуги), то есть проблема с доступностью системы.

ПервыйEureka, это гарантирует AP (доступность), что мы и собираемся сделать сегодня.ZooKeeperТо, как это обрабатывается, гарантирует CP (согласованность данных).

Протоколы консенсуса и алгоритмы

Чтобы решить проблему согласованности данных, в результате непрерывных исследований ученых и программистов появилось множество протоколов и алгоритмов согласованности. Например, 2PC (двухэтапная фиксация), 3PC (трехфазная фиксация), алгоритм Paxos и т. д.

В это время, пожалуйста, подумайте над вопросом.Если учащиеся используют метод передачи заметок для распространения новостей, возникнет проблема - как я узнаю, что моя маленькая заметка была передана человеку, которому я хочу ее передать? ткань? Что, если его угнал и подделал какой-нибудь мелкий парень, верно?

В это время возникла концепция -Проблема византийских генералов. это значитПопытка добиться согласованности путем передачи сообщений по ненадежному каналу невозможна., поэтому все алгоритмы консенсусанеобходимая предпосылкаЭто безопасный и надежный канал сообщений.

И зачем решать проблему непротиворечивости данных? Подумайте об этом, если система seckill разделяет сервис на размещение заказа и добавление баллов, эти два сервиса развернуты на разных машинах, в случае, если система баллов выйдет из строя во время распространения сообщения, вы не сможете. заказать здесь без добавления баллов? Вы всегда должны следить за тем, чтобы данные с обеих сторон были непротиворечивыми, верно?

2PC (двухэтапная фиксация)

Двухэтапная фиксация — это протокол для обеспечения согласованности данных в распределенных системах.Сейчас многие базы данных используют протокол двухфазной фиксации для завершенияРаспределенная транзакцияобработка.

Прежде чем представить 2PC, давайте подумаем, что не так с распределенными транзакциями?

Возьмем также две системы оформления заказа и начисления баллов в системе seckill в качестве примера (думаю, вас всех может стошнить 🤮🤮🤮), мы отправим сообщение в систему баллов после размещения заказа в это время, чтобы сообщить это то, что пора увеличивать очки. Если мы просто отправляем сообщение и не получаем ответа, как наша система заказов может узнать, что система баллов получила сообщение? Если мы добавим процесс получения ответа, то когда система баллов получит сообщение, она вернет сообщение в систему заказов.Response, но в середине были колебания сети, ответное сообщение не было отправлено успешно, система заказов думала, что сообщение системы баллов не удалось получить? Откатывает ли он транзакцию? Но в это время система баллов успешно получила сообщение, она обработает сообщение и добавит баллы пользователю.В это время баллы будут добавлены, но заказ не был успешно размещен.

Итак, что нам нужно решить, так это то, что в распределенной системе во всей цепочке вызовов обработка данных всех наших сервисов либо проходит успешно, либо терпит неудачу, то есть обработка данных всех сервисовпроблема атомарности.

В двухэтапном коммите в основном задействованы две роли: координатор и участник.

Первый этап: когда должна быть выполнена распределенная транзакция, инициатор транзакции сначала инициирует запрос транзакции координатору, а затем координатор отправляет запрос транзакции всем участникам.prepareЗапрос (включая содержание транзакции) сообщает участникам, что вам необходимо выполнить транзакцию. Если вы можете выполнить отправленное мной содержимое транзакции, то сначала выполните ее, но не отправляйте. Пожалуйста, ответьте мне после выполнения. Затем участник получаетprepareсообщение, они начнут выполнять транзакцию (но не фиксировать) и будутUndoиRedoИнформация заносится в журнал транзакций, после чего участники сообщают координатору о своей готовности.

Второй этап: второй этап в основном предназначен для координатора, чтобы решить, может ли следующая транзакция быть зафиксирована в соответствии с отзывами участников, то есть зафиксировать транзакцию или откатить транзакцию.

как в этот развсе участникиВсе вернули подготовленное сообщение, а транзакция в это время отправлена, и координатор отправит ее всем участникам в это время.Commitпросить, когда участник получаетCommitКогда запрос будет сделан, ранее выполненная транзакция будет выполнена.совершить действие, ответ об успешной отправке будет отправлен координатору после завершения отправки.

И если не все участники вернули подготовленное сообщение на первом этапе, то координатор отправит сообщение всем участникам в это времятранзакция откатаrollbackпросить, участник получитоткатить транзакцию, сделанную на первом этапе, а затем вернуть ситуацию обработки координатору, и, наконец, координатор возвращает результат сбоя обработки инициатору транзакции после получения ответа.

Лично я считаю, что 2PC все еще относительно безвкусен, потому что по сути он решает только атомарную проблему каждой транзакции, а также приносит много проблем.

• проблема единой точки отказа, если координатор зависает, то вся система находится в недоступном состоянии.
• проблема с блокировкой, то есть когда координатор отправляетprepareЗапрос, если участник сможет его обработать после получения, он обработает транзакцию, но не отправит ее.В это время ресурс будет занят и не освобожден.Если в это время координатор зависнет, то эти ресурсы не будут выпущен снова. , что может сильно повлиять на производительность.
• несогласованность данных, например, когда на втором этапе координатор отправил только частьcommitЗапрос зависает, а это значит, что участник, получивший сообщение, отправит транзакцию, а не полученная позже транзакция не будет отправлена, тогда будет проблема несогласованности данных в это время.

3PC (трехэтапная фиксация)

Из-за ряда проблем в 2PC, таких как единая точка, дефекты механизма отказоустойчивости и т. д., что приводит к3PC (трехэтапная фиксация). Так что же это за три этапа?

Не понимайте ПК как персональный компьютер, на самом деле это аббревиатура от Phase-commit, то есть фазовая фиксация.

1. Стадия CanCommit: Координатор отправляет всем участникамCanCommitзапрос.Получив запрос, участник проверит, может ли транзакция быть выполнена в соответствии с его собственной ситуацией.Если это возможно, он вернет ответ YES и войдет в состояние подготовки, в противном случае он вернет NO.
2. Этап предварительной фиксации: Координатор решает, можно ли сделать следующее в соответствии с ответом участника.PreCommitработать. Если вышеуказанные участники вернут YES, то координатор отправит сообщение всем участникамPreCommitпредварительная отправка запросов,После того, как участник получит запрос на предварительную фиксацию, транзакция будет выполнена, а информация об отмене и повторении будет записана в журнал транзакций.и, наконец, возвращает координатору успешный ответ, если участник успешно выполнил транзакцию. Если на первом этапе координатор получаетлюбой НЕТинформация илиВ течение определенного времениЕсли ответ от всех участников не будет получен, транзакция будет прервана, всем участникам будет отправлен запрос на прерывание (abort), после получения участником запроса на прерывание транзакция будет немедленно прервана, либо не будет получена в течение определенного периода времени по запросу координатора, он также прерывает транзакцию.
3. Стадия DoCommit: Этот этап на самом деле2PCВторой этап аналогичен, если координатор принимает всех участниковPreCommitДА ответ на фазу, координатор отправит сообщение всем участникамDoCommitпросить,После того, как участник получит запрос DoCommit, транзакция будет зафиксирована., после завершения он вернет ответ координатору, а координатор завершит транзакцию после получения ответа об успешной транзакции, возвращенного всеми участниками. Если координаторPreCommitсценаПолучил какое-либо НЕТ или не получил ответы от всех участников в течение определенного периода времени, то будет отправлен запрос на прерывание, и после того, как участник получит запрос на прерывание,Через лог отката, записанный вышеЧтобы выполнить операцию отката транзакции и сообщить статус отката координатору, координатор прерывает транзакцию после получения сообщения, возвращенного участником.

вот3PCНа блок-схеме успешной среды вы можете увидеть3PCВо многих местах выполняется обработка прерывания по тайм-ауту, например, координатор будет обрабатывать прерывание транзакции, чтобы получить все подтверждающие сообщения в течение заданного времени.Сокращение времени блокировки синхронизации. Следует также отметить, что,3PCсуществуетDoCommitЕсли вы не получаете запрос, представленный участниками, координатор Pepth Pechnation, отправляет транзакцию, она будет осуществлять транзакцию в течение определенного времени представления. Зачем это делать? Потому что в это время мы увереныГарантируется, что все координаторы на первом этапе вернули ответы, которые могут выполнять транзакции., на этот раз у нас есть причинаДоверяйте тому, что другие системы могут выполнять и фиксировать транзакции,такнесмотря наНезависимо от того, отправил ли координатор сообщение участникам, участники совершат транзакцию на третьем этапе.

Короче,3PCПроблема блокировки хорошо решается с помощью ряда механизмов тайм-аута, но самая важная согласованность не была решена фундаментально, как, например, вPreCommitНа этом этапе, когда участник получает запрос, другие участники и координатор вешают трубку или происходит сетевой раздел, в это время участник, получивший сообщение, совершит транзакцию, что приведет к несогласованности данных.

Следовательно, для решения проблемы согласованности необходимо полагаться наPaxosАлгоритмы ⭐️ ⭐️ ⭐️ .

Алгоритм `Paxos`

Paxosалгоритм основан наПередача сообщений и отказоустойчивый алгоритм консенсуса, который в настоящее время признан одним из самых эффективных алгоритмов для решения задач распределенной непротиворечивости.Проблема, которую он решает, заключается в том, как согласовать значение (разрешение) в распределенной системе..

существуетPaxosТри главные роли вProposer提案者,Acceptor表决者,Learner学习者.Paxosалгоритм и2PCТочно так же есть две стадии, которыеPrepareиacceptсцена.

подготовка стадии

• Proposer提案者: ответственный за представлениеproposal, каждый предлагающий сначала получитглобально уникальный, добавочный номер предложения N, то есть уникальный номер N во всем кластере, а затем присвоить этот номер предложению сделать, вПервый этап — разослать всем избирателям только номер предложения..
• Acceptor表决者: каждый избиратель находится вacceptПосле предложения номер предложения N будет записан локально, так что в каждом избирателе будет сохранено предложение, которое было принято.Предложение с наибольшим числом, число которых предполагается равнымmaxN. Каждый избиратель будет толькоacceptЧисло больше, чем ваш собственный местныйmaxN, и при одобрении предложения голосующий будет отвечать на предложение с наибольшим номером, который был принят ранее.Proposer.

НижеprepareБлок-схема этапа, вы можете обратиться к ней.

принять этап

когда есть предложениеProposerПосле поднятия, еслиProposerполучил более половиныAcceptorодобрение (Proposerсогласен), то в это времяProposerотдам всеAcceptorОтправьте реальное предложение (можно понимать это как первый этап пробы), на этот разProposerВысылается содержание предложения и номер предложения.

Получив запрос предложения, избиратель снова сравнит самый большой номер предложения, которое было одобрено, с номером предложения.больше или равнонаибольший номер предложения, которое было одобрено, затемacceptпредложение (в этом случае содержание предложения выполнено, но не представлено), то ситуация возвращается кProposer. Если не устраивает, не отвечайте или верните НЕТ.

когдаProposerполучил более половиныaccept, то он будет отправлен всемacceptorОтправьте запрос на подачу предложения. Следует отметить, что, поскольку вышеизложенное составляет лишь более половиныacceptorСодержание предложения утверждено и реализовано, а содержание неутвержденного предложения не реализовано, поэтому на этот раз необходимок неутвержденномуacceptorОтправьте содержание предложения и номер предложения и дайте ему возможность выполнить и отправить безоговорочно, а для тех, кто ранее одобрил предложениеacceptorзаПросто отправьте номер предложения,позволятьacceptorПросто сделайте коммит.

и еслиProposerЕсли более половиныacceptтогда это будетприращениеДолженProposalчисло, затемповторно войтиPrepareсцена.

заLearnerкак научитьсяAcceptorСодержание утвержденного предложения существует много способов, читатели могут узнать сами, и я не буду здесь слишком много объяснять.

Проблема бесконечного цикла с алгоритмом `paxos`

На самом деле это немного похоже на ссору между двумя людьми.Сяо Мин сказал, что я прав, а Сяо Хун сказал, что я прав.Никому не будет позволено драться друг с другом по причине.🤬🤬.

Например, в это время предлагающий P1 предлагает предложение M1, которое завершено.Prepareсценическая работа, на этот разacceptorЗатем было одобрено M1, но в это время предлагающий P2 также предложил предложение M2, которое также завершилоPrepareсценическая работа. Тогда схема P1 уже не может быть одобрена на втором этапе (потому чтоacceptorM2, который больше, чем M1, был одобрен), поэтому схема автоинкремента P1 становится повторным входом M3.Prepareэтап, затемacceptor, и одобрил новую программу M3, он больше не может утверждать M2, в это время M2 автоматически добавляется для вводаPrepareсцена. . .

И так далее и тому подобное, бесконечное предложение навсегда, вот чтоpaxosПроблема бесконечного цикла алгоритма.

Итак, как решить эту проблему? Это очень просто, легко поссориться, когда слишком много людей, я сейчасразрешить предложениеВот и все.

Извлечь `ZAB`

Архитектура «Хранитель зоопарка»

В качестве превосходной, эффективной и надежной системы распределенной координации,ZooKeeperОн не используется напрямую при решении проблем согласованности распределенных данных.Paxos, но специально настроенный протокол согласованности, называемыйZAB(ZooKeeper Automic Broadcast)Атомарный широковещательный протокол, который хорошо поддерживаетсяаварийное восстановление.

Три роли в `ЗАБ`

и введениеPaxosто же, во введенииZABПрежде чем договориться, давайте сначала разберемсяZABтри главные роли вLeader 领导者,Follower跟随者,Observer观察者.

• Leader: в кластереЕдинственный обработчик запросов на запись, чтобы иметь возможность инициировать голосование (голосование также за запросы на запись).
• Follower: может получить запрос клиента, если это запрос на чтение, вы можете обработать его самостоятельно,Если это запрос на запись, он будет переадресован «Лидеру».. участвовать в голосовании в ходе избирательного процесса,иметь право избирать и быть избранным.
• Observer: то есть без права голоса и быть избраннымFollower.

существуетZABв соглашенииzkServer(то есть общий термин для трех упомянутых выше ролей).широковещательное сообщениеиаварийное восстановление.

режим рассылки сообщений

Грубо говоряZABКак протокол обрабатывает запросы на запись, мы не говорим, что толькоLeaderМожет ли он обрабатывать запросы на запись? тогда нашFollowerиObserverтебе тоже нужноОбновлять данные синхронноШерстяная ткань? Данные не всегда можно найти только вLeaderОн был обновлен в Китае, но другие символы не были обновлены, верно?

не так лиПоддерживайте согласованность данных в кластереЧто ж? Если бы это были вы, что бы вы сделали?

Ерунда, первый шаг точно нуженLeaderнапишу запространслироватьвыйди, позвольLeaderпроситьFollowersСоглашаться ли на обновление, если согласны больше половиныFollowerиObserverобновление (иPaxosТакой же). Конечно, это немного неверно, нарисуйте картинку, чтобы понять.

В порядке. . . Выглядит очень просто, вроде понятно 🤥🤥🤥. эти двоеQueueОткуда это? ответZABнужно позволитьFollowerиObserverГарантированный заказ. Что такое последовательность, например, у меня есть запрос на запись A сейчас, в это времяLeaderШироковещательный запрос A, потому что требуется только половина согласия, поэтому в настоящее время может быть одно согласие.FollowerF1 не получен по сетевым причинам, иLeaderБыл передан другой запрос B. Из-за сетевых причин F1 сначала получил запрос B, а затем получил запрос A. В это время другой порядок обработки запросов приведет к другим данным, поэтомупроблема несоответствия данных.

так вLeaderс этой целью они служат друг другуzkServerподготовил одиночередь, сообщения отправляются в порядке очереди. Так как протокол **пройденTCP** Для сетевого общения гарантируется порядок отправки сообщений, а также гарантируется порядок получения.

Кроме того, вZABтакже определяетГлобальный монотонно возрастающий идентификатор транзакцииZXID, который представляет собой 64-битный тип, где старшие 32 бита представляютepochs, младшие 32 бита представляют собой идентификатор транзакции.epochбудет основываться наLeaderизменяется, когдаLeaderповесил трубку, новыйLeaderКогда у власти век(epoch) измененный. Нижние 32 бита можно просто понимать как идентификатор инкрементной транзакции.

Причиной определения этого также является последовательность, каждыйproposalсуществуетLeaderтребуется после генерациичерез егоZXIDСортировать, для обработки.

режим восстановления после сбоя

Когда дело доходит до восстановления после сбоя, мы в первую очередь должны упомянутьZABсерединаLeaderАлгоритм выборов, когда система выходит из строя, самое большое влияние должно бытьLeaderавария, потому что у нас есть только одинLeader, так когдаLeaderКогда что-то пойдет не так, нам обязательно понадобятся новые выборыLeader.

LeaderВыборы можно разделить на два отдельных этапа, первый из которых мы упомянулиLeaderВремя простоя требует переизбрания, а второе - когдаZookeeperсистема при запускеLeaderИнициализировать выборы. Позвольте мне сначала представитьZABКак выполняются выборы инициализации.

Предполагая, что у нас есть 3 машины в нашем кластере, это означает, что нам нужно больше двух машин для согласования (более половины). Например, когда мы начинаемserver1, это будет сначалапроголосуй за себя, содержание голосования принадлежит серверу.myidиZXID, так как инициализацияZXIDвсе 0, в это времяserver1Выдано голосование (1,0). Но в это времяserver1голос всего 1, поэтому его нельзя использовать какLeader, он все еще находится в фазе выборов, поэтому весь кластер находится вLookingгосударство.

тогдаserver2Запущенный, он сначала будет голосовать за себя (2,0) и транслировать информацию о голосовании (server1Кроме того, в то время у него просто не было других серверов),server1при полученииserver2будет сравнивать информацию о голосовании со своей собственной информацией о голосовании.Сначала он будет сравниватьZXID,ZXIDБольшим приоритетом являетсяLeader, если они одинаковые, то сравнитеmyid,myidбольшой приоритет какLeader. Итак, в это времяserver1Находитьserver2больше подходит дляLeader, он изменит свою информацию о голосовании на (2,0) и затем транслирует ее, а затемserver2После его получения обнаруживается, что он такой же, как и ваш, без внесения изменений, а ваш собственныйБыло подано более половины голосов,ноКонечноserver2заLeader,server1также установить свой собственный сервер наFollowingстатьFollower. Весь сервер начинается сLookingстал нормальным.

когдаserver3Запуск обнаружил, что кластер не вLookingгосударство, оно начнется непосредственно сFollowerприсоединиться к кластеру.

или первые триserverнапример, если в процессе запуска всего кластераserver2Если зависнет, то как будет переизбираться весь кластер?LeaderШерстяная ткань? По сути, это похоже на инициализацию выборов.

Во-первых, несомненно, что оставшиеся дваFollowerбудет владеть государствомотFollowingстатьLookingгосударство, то каждыйserverСначала будет голосовать за себя, как при первоначальном голосовании (здесь это как раз тот случайzxidЭто может быть уже не 0, здесь случайное число для удобства).

Предположениеserver1Голосуйте за себя как (1,99) и транслируйте другимserver,server3Так же сначала проголосую за себя (3,95), а потом и другим сообщуserver.server1иserver3В этот момент они получат информацию о голосовании друг друга, и, как и в начале выборов, они также будут сравнивать свои голоса с полученными голосами (zxidСначала большой, если такой же, тоmyidбольшой первый). В настоящее времяserver1получилаserver3голосов сочли, что они не имеют собственного соответствия и поэтому остались без изменений,server3Получатьserver1После результата голосования я обнаружил, что он больше подходит, чем мой, поэтому я изменил голосование на (1,99) и транслировал его, и, наконец,server1Получил и обнаружил, что больше половины голосов пройдено, и поставил себя какLeader,server3также становитсяFollower.

Пожалуйста, обрати вниманиеZooKeeperЗачем устанавливать нечетное количество узлов? Например, нас здесь трое, если один зависнет, мы все еще можем нормально работать, если двое зависнут, мы не сможем нормально работать (у нас не более половины узлов, поэтому голосование и другие операции не могут быть выполненный). А допустим у нас сейчас четыре, и если один зависнет, то работать будет,Но не работает после двух зависаний., это то же самое, что и три, а три на единицу меньше четырех, и выгоды те же, поэтомуZookeeperРекомендуется нечетное числоserver.

затем закончилZABсерединаLeaderПосле выборов мы узнаем об этом большеаварийное восстановлениеЧто это?

На самом деле, основнойКогда машина в кластере зависает, как весь кластер обеспечивает согласованность данных?

если толькоFollowerповесить трубку, и повесить трубку реже, чем в половине случаев, потому что мы сказали в началеLeaderОчередь будет поддерживаться в середине, поэтому не нужно беспокоиться о несогласованности данных, вызванной тем, что последующие данные не будут получены.

еслиLeaderЕсли он зависнет, это будет проблематично.Нам обязательно нужно сначала приостановить службу.Lookingсостояние, а затем продолжитьLeader(я упоминал выше), но это будет разделено на две ситуации, а именноУбедитесь, что предложения, которые были представлены лидером, наконец могут быть представлены всеми последователями.ипропускать предложения, которые были отклонены.

Что значит гарантировать, что предложение, внесенное лидером, в конечном итоге может быть представлено всеми последователями?

ПредположениеLeader (server2)Отправитьcommitзапрос (забыл посмотреть режим трансляции сообщения выше), он отправил наserver3, а затем отправить вserver1Внезапно положили трубку. В это время, когда мы переизберемся, если мы положимserver1в видеLeader, то обязательно будет несогласованность данных, т.к.server3Обязательно отправлю прямо сейчасserver2послалcommitзапрошенное предложение, в то время какserver1Не получил вообще, так что выкину.

Как это решить?

Умные одноклассники обязательно спросят,В настоящее времяserver1невозможно статьLeader, так какserver1иserver3будем сравнивать при голосованииZXID, а на этот разserver3изZXIDопределенно лучше, чемserver1большой. (Если не понял, можно посмотреть предыдущий алгоритм выборов)

Так что же значит пропускать предложения, которые уже были отклонены?

ПредположениеLeader (server2)В этот момент предложение N1 согласовывается, и транзакция оформляется сама собой и рассылается всемFollowerхотетьcommitзапрос, но он зависает в это время, и его необходимо перезапустить в это времяLeaderвыборы, как в этот разserver1заLeader(Это не имеет значения). Но через некоторое время этоповесить трубкуLeaderснова восстановлен, и в этот момент он определенно будет действовать какFollowerдля входа в кластер как удостоверение, следует отметить, что только сейчасserver2согласился представить предложение N1, но другиеserverне получил егоcommitинформация, так другоеserverОтправить это предложение N1 повторно невозможно, поэтому возникнет проблема несоответствия данных, поэтомуПредложение N1 в конечном итоге придется отбросить.

Некоторые теоретические знания Zookeeper

понялZABСоглашения недостаточно, это простоZookeeperспособ внутренней реализации, и как мы проходимZookeeperА как насчет некоторых типичных сценариев применения? Например, управление кластером, распределенные блокировки,MasterВыборы и прочее.

Это включает в себя, как использоватьZookeeperДа, но нам все еще нужно понять несколько концепций, прежде чем использовать его. НапримерZookeeperизмодель данных,механизм сеанса,ACL,Наблюдательный механизми Т. Д.

модель данных

zookeeperСтруктура и стандарт хранения данныхUnixФайловая система очень похожа, с множеством дочерних узлов (деревьев), висящих под корневым узлом. ноzookeeperВ файловой системе нет понятия каталогов и файлов, ноиспользовалznodeкак узел данных.znodeдаzookeeperНаименьшая единица данных в , каждыйznodeДанные могут быть сохранены на всех узлах, а подузлы также могут быть смонтированы для формирования древовидного пространства имен.

каждыйznodeиметь свои собственныеТип узлаистатус узла.

Типы узлов можно разделить напостоянный узел,Постоянные последовательные узлы,временный узелиУзел временной последовательности.

• Постоянные узлы: после создания они существуют до тех пор, пока не будут удалены.
• Постоянные последовательные узлы: родительский узел может быть его дочерним узломСоблюдайте порядок создания, этот порядок отражается вимя узлаВыше строка из 10 цифр автоматически добавляется после имени узла, начиная с 0.
• Эфемерный узел: жизненный цикл эфемерного узла такой же, как и усеанс клиентаграница,Когда сеанс исчезает, узел исчезает. временный узелтолько листовые узлы, не может создавать дочерние узлы.
• Временный последовательный узел: родительский узел может создать временный узел, который поддерживает порядок (такой же, как предыдущий постоянный последовательный узел).

Состояние узла содержит множество атрибутов узла, таких какczxid,mzxidподожди, вzookeeperв использованииStatЭтот класс сохраняется. Ниже я перечисляю некоторые объяснения атрибутов.

• czxid:Created ZXID, узел данныхСоздайтеИдентификатор транзакции времени.
• mzxid:Modified ZXID,узелпри последнем обновленииномер транзакции.
• ctime:Created Time, время создания узла.
• mtime:Modified Time, время последнего изменения узла.
• version: номер версии узла.
• cversion:дочерний узелномер версии.
• aversion: узлыACLномер версии.
• ephemeralOwner: Сеанс, создавший узелsessionID, что равно 0, если узел является постоянным.
• dataLength: Длина содержимого данных узла.
• numChildre: количество дочерних узлов этого узла, 0, если это временный узел.
• pzxid: идентификатор транзакции списка дочерних узлов узла при последнем изменении; обратите внимание, что это идентификатор дочернего узла.список, а не содержание.

беседа

Я думаю, это определенно знакомо друзьям, занимающимся бэкенд-разработкой, не так ли?session? Толькоzkклиент и сервер черезTCPДлинное соединениеПоддерживаемый механизм сеанса, собственно, для сеанса можно понимать какоставайся на связи.

существуетzookeeperВ сеансе есть соответствующие события, такие какCONNECTION_LOSS 连接丢失事件,SESSION_MOVED 会话转移事件,SESSION_EXPIRED 会话超时失效事件.

ACL

ACLзаAccess Control Lists, который является элементом управления разрешениями. существуетzookeeperСуществует 5 видов разрешений, определенных в , а именно:

• CREATE: Разрешение на создание дочерних узлов.
• READ: Разрешение на получение данных узла и списка дочерних узлов.
• WRITE: Разрешение на обновление данных узла.
• DELETE: Разрешение на удаление дочерних узлов.
• ADMIN: Разрешение на установку ACL узла.

Наблюдательный механизм

Watcherдля слушателей событий, даzkОчень важная фича, от нее зависят многие функции, она чем-то похожа на метод подписки, то есть клиент отправляет сервер на серверрегистрназначенныйwatcher, когда сервер встречаетwatcherопределенные события или запросы будутОтправка уведомлений о событиях клиентам, клиент находит свое определение после получения уведомленияWatcherпотомВыполнить соответствующий метод обратного вызова.

Несколько типичных сценариев применения Zookeeper

Так много теоретических знаний было сказано ранее, что вы можете растеряться, какая польза от этих вещей? Что я могу сделать? Не волнуйся, слушай меня медленно.

выбрать главное

Помните временный узел, о котором мы говорили выше? так какZookeeperСильная согласованность может быть хорошо гарантирована вГарантировать глобальную уникальность создания узла в случае высокого параллелизма(т. е. один и тот же узел не может быть создан повторно).

Используя эту функцию, мы можемРазрешить нескольким клиентам создать указанный узел, успешное созданиеmaster.

Однако, если этоmasterЧто, если я повешу трубку? ? ?

Как вы думаете, зачем мы создаем временные узлы? Помните жизненный цикл эфемерных узлов?masterОзначает ли зависание, что сеанс отключен? Означает ли отключенный сеанс, что узел ушел? все еще помнюwatcher? можем мыпусть другой неmasterУзел слушает состояние узла, например, мы мониторим родительский узел этого временного узла, если количество дочерних узлов меняется, значитmasterповесить трубку, на этот раз мыАктивировать функцию обратного вызова для переизбрания, либо мы напрямую мониторим состояние ноды, можем судить по тому, потеряла ли нода связьmasterВешается ли трубка и так далее.

В общем, мы можемВоспользуйтесь эфемерными узлами, состояниями узлов иwatcherреализовать функцию выбора основного, временные узлы в основном используются для выбора, статуса узла иwatcherможно использовать для сужденияmasterдеятельность и провести перевыборы.

Распределенная блокировка

Существует множество способов реализации распределенных блокировок, таких какRedis, база данных ,zookeeperЖдать. На мой взглядzookeeperРеализовать распределенные блокировки очень и очень просто.

Мы упоминали вышеzk гарантирует глобальную уникальность создания узла в случае высокого параллелизма., вы можете видеть, что эта штука может сделать. Реализация блокировки взаимного исключения, и поскольку она может быть распределенной, она может реализовать распределенную блокировку.

Как этого достичь? По сути, это то же самое, что и выбор мастера, и мы также можем использовать для этого создание временных узлов.

Во-первых, как получить блокировку, из-за уникальности создания узлов мы можем позволить нескольким клиентам одновременно создавать временный узел,Если создание прошло успешно, это означает, что блокировка получена.. Затем клиент, который не получает блокировку, также создает неосновной узел, подобный неосновному узлу, выбранному выше.watcherСледите за состоянием узла.Если мьютекс освобождается (клиент, который установил блокировку, может быть недоступен, или клиент активно снимает блокировку), можно вызвать функцию обратного вызова для восстановления блокировки.

zkне нужноredisЗатем рассмотрим проблему, что блокировка не может быть снята, потому что когда клиент зависает, нода тоже зависает, и блокировка тоже снимается. Очень просто ответить?

Можно ли это использоватьzookeeperОдновременноОбщие блокировки и эксклюзивные блокировкиШерстяная ткань? Ответ положительный, но все немного сложнее.

все еще помнюупорядоченные узлы?

В это время я оговариваю, что все созданные узлы должны быть в порядке.При запросе на чтение (для получения общей блокировки), еслиНи один узел меньше самого себя или узлы меньше себя не являются запросами на чтение., вы можете получить блокировку чтения, а затем начать чтение.Если есть запрос на запись на узле меньше, чем он сам, текущий клиент не может получить блокировку чтения и может только ждать завершения предыдущего запроса на запись.

Если вы запрос на запись (для получения эксклюзивной блокировки), еслинет узла меньше, чем он сам, это означает, что текущий клиент может напрямую получить блокировку записи и изменить данные. Если найденоСуществует узел меньше, чем он сам, будь то операция чтения или операция записи, текущий клиент не может получить блокировку записи, ожидая завершения всех предыдущих операций.

Это хорошая реализация общих и монопольных блокировок одновременно, и, конечно же, есть оптимизации, например, когда блокировка снята, она уведомляет всех ожидающих клиентов, вызываястадный эффект. На данный момент вы можете сделать это, заставив ожидающие узлы слушать только узлы перед ними.

Как это сделать? Это на самом деле очень просто, вы можете сделатьЗапрос на чтение прослушивает последний узел запроса на запись, меньший, чем он сам, а запрос на запись слушает только последний узел, меньший, чем он сам., а заинтересованные друзья могут изучить его самостоятельно.

служба имен

Как установить ID для объекта, может подумать каждыйUUID,ноUUIDСамая большая проблема в том, что это слишком долго. . . (Слишком долго не обязательно хорошо, хе-хе-хе). Тогда, если позволяют условия, можем ли мы использоватьzookeeperдобиться этого?

мы упоминали ранееzookeeperчерездревовидная структурадля хранения узлов данных, то есть для каждого узлаПолный путь, он должен быть уникальным, мы можем использовать полный путь к узлу в качестве метода именования. И что еще более важно, путь — это то, что мы можем определить сами, что облегчает понимание наших настроек идентификатора для некоторых семантических объектов.

Управление кластером и реестр

Смотри сюда, тебе не кажетсяzookeeperОн такой мощный, как он может быть таким способным!

Не волнуйтесь, он может многое. Может быть у нас есть такое требование, нам нужно знать, сколько машин работает во всем кластере, мы хотим собирать данные о статусе выполнения каждой машины в толпе и выполнять онлайн и оффлайн операции на машинах в кластере.

иzookeeperЕстественно поддерживаетсяwatcherИ эфемерные узлы могут очень хорошо выполнять эти требования. Мы можем создать временный узел для каждой машины и следить за его родительским узлом.Если список дочерних узлов изменится (мы можем создать и удалить временный узел), то мы можем использовать привязку к его родительскому узлу.watcherОсуществляйте мониторинг состояния и обратные вызовы.

Что касается регистрационного центра, то он тоже очень простой, мы тоже пускаемпоставщики услугсуществуетzookeeperсоздать временный узел вip、port、调用方式писать в узел, когдапотребители услугКогда его нужно будет вызвать, онНайдите список адресов (IP-порт или что-то еще) соответствующего сервиса через реестр, и кэшировать его локально (для будущих вызовов), когда потребители звонят в службы, они не будут обращаться в центр регистрации, а напрямую использовать алгоритм балансировки нагрузки, чтобы получить сервер поставщика услуг из списка адресов для вызова службы.

Когда сервер поставщика услуг выходит из строя или отключается, соответствующий адрес удаляется из списка адресов поставщика услуг. В то же время реестр отправит новый список адресов службы на машину потребителя службы и кэширует его на машине потребителя (конечно, вы можете позволить потребителю контролировать узел, я помнюEurekaСначала попробую и ошибусь, потом обновлю).

Суммировать

Видя, что одноклассники здесь такие терпеливые 👍👍👍, если вы считаете, что я хорошо пишу, пожалуйста, поставьте мне палец вверх.

Не знаю, помните ли вы еще, что я сказал 😒.

В этой статье я познакомлю вас сzookeeperЭто мощная распределенная координационная структура. Теперь кратко разберемся в содержании всей статьи.

• Разница между распределенным и кластерным

• 2PC,3PCа такжеpaxosАлгоритмы Принципы и реализации этих структур соответствия.

• zookeeperСпециализированный алгоритм консенсусаZABСодержание протокола Atomic Broadcast (Leaderвыборы, восстановление после сбоя, рассылка сообщений).

• zookeeperнекоторые основные понятия, такие какACL, узел данных, сеанс,watcherмеханизм и др.

• zookeeperТипичные сценарии применения, такие как подбор мастеров, регистрационные центры и так далее.

  Если вы забыли, вы можете вернуться и прочитать его снова, чтобы снова понять его.Если у вас есть какие-либо вопросы или предложения, добро пожаловать спрашивайте 🤝🤝🤝.