предисловие
Год назад я сделал несколько важных обзоров Zookeeper, и теперь мы вернемся к нему снова и проясним некоторые причины и последствия.
предыдущая ссылка
Высокий параллелизм с нуля (1) --- основная концепция Zookeeper
Высокий параллелизм с нуля (2) --- Zookeeper реализует распределенные блокировки
Высокий параллелизм с нуля (3) --- Создание кластера Zookeeper и выбор лидера
Высокий параллелизм с нуля (4) --- распределенная очередь Zookeeper
Высокий параллелизм с нуля (5) --- Приложение центра конфигурации Zookeeper
Высокий параллелизм с нуля (6) --- Выборы мастера Zookeeper и краткий обзор его официального сайта
1. Связь между распределенными системами и Zookeeper
1.1 Централизованные службы
Начнем с процесса разработки архитектуры развертывания сервиса, по сути это не что иное, какцентрализованныйираспределенный, централизованный означает, что все, что я делаю, делается одной машиной. Распределенная — это совместная доработка нескольких серверов. Итак, в начале мы обычно начинаем с сервера, развертываем наши службы, а затем какие-то старые подпрограммы.Веб-приложения развертываются на Tomcat, чтобы открыть порт 8080 для предоставления служб, а затем открывается необходимая служба базы данных.Доступен порт 3306. . Его преимущество в том, что структура, развертывание и архитектура проекта относительно просты.
Затем, в зависимости от развития бизнеса для расширения, расширение также можно разделить на два пути: одно - горизонтальное расширение, другое - вертикальное расширение. Так как один сделать нельзя, то либо повышайте производительность этого сервера, либо устанавливайте еще несколько вместе. Но давайте подумаем, дело не в том, что люди будут послушны серверному устройству, раз эта машина зависнет, то и вся зависнет. Более того, покупка мейнфреймов, а также персонал, занимающийся исследованиями и разработками, и обслуживающий персонал стоят больших денег. Вот расширение для вас«Закон Мура»
В любом случае, проще говоря, я трачу вдвое больше денег и не могу купить вдвое большую производительность. Но горизонтальное расширение другое: если один человек не может победить, достаточно попросить нескольких людей сражаться вместе?
1.2 Перейти к кампании IOE
Слоган, сделанный Alibaba, конкретный момент - мини-компьютер IBM, база данных Oracle, высокопроизводительное хранилище EMC, вы также можете узнать об этом, если вам интересно. Потому что проблема, с которой столкнулись в то время, заключалась в том, что если бы предприятию нужно было улучшить производительность одной машины, стоимость была бы очень высокой, а соотношение цены и качества было бы чрезвычайно низким. Я до сих пор боюсь того и этого в течение всего дня, и вся служба остановится, когда она выйдет из строя. Постепенно откликнулись многие отечественные компании, и началось распространение.
1.3 Распределенные службы
Распределенная система имеет свое конкретное определение: это распределенная система.Аппаратные или программные компоненты, распределенные по разным сетевым компьютерам, которые взаимодействуют и координируют друг с другом только посредством передачи сообщений.система. Итак, это группа компьютеров, работающих вместе, чтобы предоставлять услуги внешнему миру, но для пользователя это выглядит так, как будто это делает одна машина.
Есть много функций, примерно следующие 5:
- Распределение: здесь несколько компьютеров размещаются в разных местах.
- Одноранговые: несколько в кластерерабочий узелОни все одинаковые, выполняют одну и ту же работу. И есть понятие копия
- Параллелизм: несогласованность данных может быть вызвана тем, что несколько машин обрабатывают часть данных одновременно.
- Глобальные часы: последовательность событий на нескольких хостах повлияет на результаты, что также является очень сложной проблемой в распределенных сценариях.
- Различные сбои: узел не работает, сеть не в порядке... аварийные ситуации
1.4 Несколько проблем, часто встречающихся в распределенных сценариях
- Нарушение связи: на самом деле это проблема сети, приводящая к несогласованности данных в состоянии нескольких узлов.
- Изоляция сети: на самом деле это внутренняя норма каждой подсети, но сеть всей системы ненормальна. Проблемы, вызывающие несогласованность локальных данных
- Проблема с узлом
- Распределенное три состояния: успех, сбой и время ожидания для каждой проблемы, вызванной тремя состояниями. И отправка запроса, и результирующий ответ могут быть утеряны, и невозможно определить, было ли сообщение отправлено/обработано успешно
- Потеря данных: обычно это решается с помощью механизма реплик, чтения с других узлов или для узлов с отслеживанием состояния. Потеря данных может быть решена путем восстановления состояния.
Принцип обработки исключений: любые исключения, рассмотренные на этапе проектирования, должны исходить из того, что они возникают в реальной эксплуатации.
1.5 Критерии производительности для измерения распределенных систем
-
Производительность: в основномПропускная способность, задержка ответа, возможность параллелизма. Общий объем данных, которые система может обработать в определенное время, обычно измеряется общим объемом данных, обрабатываемых системой в секунду, а задержка ответа относится ко времени, необходимому для выполнения функции. Параллелизм — это возможность одновременного выполнения функции, обычно измеряемая числом запросов в секунду.
-
Доступность: способность корректно предоставлять услуги перед лицом различных исключений. Например, 5 9, о которых мы часто говорим, относится только к 5 минутам простоя в год. 6 девяток это 31 секунда
-
Масштабируемость: относится к эффекту повышения производительности системы за счет расширения масштаба машины.
-
Согласованность: управление репликами
Но эти стандарты слишком высоки в одном аспекте, что приведет к ухудшению другого аспекта.Например, если нам нужно добиться высокой доступности, нам может понадобиться несколько копий, но в состоянии нескольких копий трудно согласованность данных, чтобы сделать это. Тогда трудно добиться низкой задержки при высокой пропускной способности, поэтому нам необходимо рассмотреть собственные бизнес-сценарии.
1.6 Расширения для согласованности
-
Строгая согласованность: после завершения операции записи операция чтения должна иметь возможность считывать последние данные, чего очень сложно добиться в распределенных сценариях, таких как алгоритм Paxos, механизм Quorum и протокол ZAB.
-
Слабая согласованность: он не обещает, что записанное значение может быть прочитано немедленно, или сколько времени потребуется для согласования данных, но он попытается гарантировать, что он достигнет определенного уровня времени (например, XX часов, XX минут). , и XX секунд спустя). Может быть достигнуто согласованное состояние.
У него также есть особый случай, называемый конечной согласованностью, который должен обеспечить согласованность данных как можно быстрее. Но насколько это быстро, точного определения нет. Например, если женский билет хочет съесть жареного цыпленка, вы заказываете еду на вынос, но райдер Meituan, вы голодны?Райдер не может сказать, когда его доставят.Он может только сказать, что его доставят как как можно скорее. Вот что это значит.
Поскольку окончательная согласованность слишком слаба, у нас все еще есть некоторые особые случаи, когда возникает согласованность чтения-записи. Это означает, что пользователи всегда могут впервые увидеть свой собственный обновленный контент, когда они читают результаты своего собственного письма. Это похоже на WeChat. .Так же, как и круг друзей, мы обязательно дадим посмотреть вещи, которые отправляем в WeChat, но если ваши друзья увидят это сразу после того, как вы отправите, то точно не скажешь👀.
Есть также некоторая монотонность чтения, причинно-следственная связь не будет объяснена, и заинтересованные друзья могут искать сами.
В общем, чтобы обеспечить высокую доступность системы, предотвратить проблемы, вызванные едиными точками отказа, и позволить репликам, распределенным по разным узлам, нормально предоставлять услуги пользователям, в это время появился наш Zookeeper. это может помочь намРешите согласованность данных в этой распределенной системеПроблема
Чтобы решить эту проблему, нам нужно понять распределенные транзакции, алгоритм распределенного консенсуса, механизм кворума, теорию CAP и BASE, а затем мы будем постепенно расширяться.
2. Распределенные транзакции
Транзакция: используется в автономной системе хранения для обеспечения согласованности состояния данных в системе хранения. Это немного сбивает с толку при чтении? Это нормально. Скажем иначе. В широком смысле транзакция относится к ко всем операциям вещи, или все операции успешны, и необходимо, чтобы Не все терпели неудачу, промежуточных состояний нет. В узком смысле это те операции, которые выполняет база данных. Фича тоже очень простая, то есть знакомая ACID.
Каждый узел в распределенной системе знает только, успешна ли его собственная операция, но он не знает, что представляют собой другие узлы, что может привести к несогласованности состояния каждого узла, поэтому для достижения ACID на нескольких узлах и обеспечения транзакций , необходимо ввестикоординатор, то каждый узел, участвующий в транзакции, называетсяучастник
Типичная рутина — 2PC и 3PC, а затем мы будем постепенно расширяться.
2.1 Что такое 2PC
В процессе участия в транзакции будет несколько ролей.Пока давайте понимать это так.Координатор отвечает за инициирование транзакции, а участник отвечает за выполнение транзакции.
Предполагая, что есть три вышеупомянутые роли, один координатор и два участника, в настоящее время нам нужны A и B для выполнения транзакции, и мы требуем, чтобы эта транзакция была либо успешной, либо неудачной одновременно.
2PC Фаза 1: выполнение транзакции
В этот момент координаторСначала введите команду, требующую от участника A и участника B выполнить транзакцию, но не фиксировать ее.
Скажем чуть подробнее, это надо будет писать redo, undo log, блокировку ресурсов, ветку принуждения. Но после того, как выполнение будет закончено, играя непосредственно с координатором доклада, спросите, Брат, Могу ли я представить его?
С этим приходится часто сталкиваться в процессе ежедневного написания Java, то есть до этого было написано много операций, но в конце обязательно будет написана однаconn.commit()Как-то так это называетсяВыполнить, но не зафиксировать
2PC Фаза вторая: зафиксировать транзакцию
как координаторПри получении всех участников транзакции (рисунок A, B) первого этапа обратной связи (обратная связь, просто понятая как первая фаза внедрения ранее, сообщила координатору успешно), он отправляет команду всем участникам представить дела дела.
Если хотите конкретнее, то есть координатор получает обратную связь, а все участники отвечают, что могут отправлять, уведомлять участников о коммите, иначе откат
так2PC также известен как двухфазная фиксация., на самом деле он настолько прост, что делится на два шага, один выполняется, а другой подается.
4 недостатка 2PC: производительность
Глядя на весь процесс, можно увидеть, что это явно вызывает блокировку синхронизации, и каждый узел, который должен работать с базой данных, занимает ресурсы базы данных. Только когда координатор получит ответ о готовности всех узлов, координатор транзакций уведомит о фиксации или откате, а участники высвободят ресурсы после завершения операции фиксации или отката.
4 недостатка 2PC: единая точка отказа
Тогда мы только что узнали, что координатор является ядром этой транзакции. Если координатор выйдет из строя в это время, это вызовет проблему, что уведомление не может быть донесено до участников, например, не может быть получен коммит или откат, и вся транзакция будет стагнировать.
4 недостатка 2PC: несогласованность данных
Координатор отправит фиксацию или откат на втором этапе. Однако это не гарантирует, что каждый узел нормально примет команду, поэтому возможно, что участник А получает команду и отправляет транзакцию, а участник Б — нет. Так что волатильность сети — вечная причина, и от этого фактора никуда не деться.
4 недостатка 2PC: отсутствие механизма отказоустойчивости
Координатор должен получить обратную связь от всех узлов до того, как будет выдана инструкция фиксации.Если ответ какого-либо участника не получен, координатор будет ждать, и пока есть неработающий узел, вся транзакция не будет выполнена. откат.
2.2 Что такое 3ПК?
В соответствии с предпосылкой 2PC было сделано улучшение, и этап подготовки в 2PC был разделен на три этапа: можно зафиксировать, предварительно зафиксировать и выполнить фиксацию.
и импортироватьМеханизм тайм-аута: если участник транзакции не получает команду координатора на фиксацию или откат в течение указанного времени, он автоматически выполняет локальную фиксацию для решения проблемы единой точки отказа координатора.
3PC Фаза 1 может зафиксировать
Координатор сначала спросил: Эй, ребята, вы можете это сделать? Участники ответят «да» или «нет» в зависимости от их реальной ситуации.
Предварительная фиксация 3PC фазы 2
Если все участники возвращают согласие, координатор отправляет всем участникам запрос на предварительную отправку и переходит к этапу подготовки. Этап подготовки здесь фактически позволяет участникам заблокировать ресурсы, дождаться команды, а затем выполнить транзакцию. как и 2PC, выполнить, но не зафиксировать. Затем дождитесь инструкции координатора.Если вы не можете дождаться инструкции, она будет отправлена локально через определенный период времени.
However, there will also be disadvantages. For example, the coordinator successfully sends a rollback to 1 and 2 participants, and then 3 just doesn't receive it, then 3 is automatically submitted, so the timeout mechanism cannot completely guarantee the consistency of the данные.
3. Алгоритм распределенной согласованности
3.1 Алгоритм Paxos
Я не знаю, видели ли вы тот, который я написал в прошлом годуВысокий параллелизм с нуля (3) --- Создание кластера Zookeeper и выбор лидераЕсли вам нужна дополнительная информация, рекомендуется перейти к этой статье.
Алгоритм Paxos - это своего рода алгоритм, предложенный Лесилем Лэмпортом.Алгоритм согласованности на основе передачи сообщений и неисправности
Вы чувствуете себя запутанным? Ничего страшного, нам просто нужно знать, что в распределенной системе неизбежно убиваются процессы, сообщения задерживаются, дублируются, теряются... Ряд проблем, алгоритм Paxos — это то, что по-прежнему гарантирует непротиворечивость данных в этих нештатных ситуациях. Так какое это имеет отношение к Zookeeper? Zookeeper использует протокол ZAB, но нижний уровень этого протокола ZAB инкапсулирует алгоритм Paxos.
3.2 Роли, существующие в Paxos, и связь с кластером Zookeeper
Предлагающий: как следует из названия, человек, который инициирует предложение
Принимающий: они могут голосовать и могут принимать или отклонять предложения
Ученик: Если предложение принято более чем половиной Принимающих, изучите предложение.
В кластере ZooKeeper это Лидер, Последователь, Наблюдатель, что немного похоже на председателя, представителя Собрания народных представителей и народных отношений страны.Предложение внес председатель, в голосовании участвовал представитель Собрания народных представителей. , а в народе народ национальный принимали пассивно, наверное так Чувствую. По сравнению с предыдущими 2PC, 3PC для прохождения требуется только половина из них. Так что такого родаслабая консистенция, 2ПК, 3ПК относятся ксильная консистенция
3.3 Рафт-алгоритм
Пожалуйста, нажмите на эту ссылку, я верю, что вы сможете освоить ее в ближайшее время.thesecretlivesofdata.com/raft/Позвольте мне немного объяснить здесь. Это в форме PPT. В нем рассказывается, что такое Raft. Это очень легко понять. Я пропущу некоторые из предыдущих вещей и перейду сразу к теме.
Как упоминалось здесь, Raft — это протокол для реализации алгоритмов распределенного консенсуса.
Здесь предполагается, что узел имеет 3 различных состояния.
Первый, состояние последователя (без полос)
Второе состояние-кандидат (пунктирная линия)
Третий тип, состояние лидера (сплошная линия)Помните, что лидеров выбирают из кандидатов
Прежде всего, как только мы подходим, все узлы находятся в состоянии следования.
Затем все узлы-последователи ищут лидера. Когда они не могут его найти, они спонтанно становятся кандидатами на голосование (спросите других, одобряют ли они то, что я стал лидером). Что происходит, когда они не могут его найти? Должно быть, лидер вешает трубку 😂
В этот момент он отправляет предложение на голосование другим узлам, а затем другие узлы также дадут ему отзывы.Когда он получает отзывы более чем от половины узлов, он логически может стать лидером.
После этого запрос на запись данных будет отправлен непосредственно лидеру, и лидер будет транслировать его другим последователям.В это время, пока более половины узлов возвращают положительный отзыв, транзакция записи данных будет выполняется, а затем лидер отправляет им команду фиксации. , транзакция выполняется успешно.
3.4 Протокол ZAB
содержание вВысокий параллелизм с нуля (4) --- распределенная очередь Zookeeper
Базовой реализацией Zookeeper является протокол ZAB, который реализует функции восстановления после сбоя (сбой лидера) и широковещательную рассылку сообщений (клиент записывает данные в Zookeeper для обеспечения успешной записи нескольких узлов). Главное — обеспечить, чтобы транзакции, отправленные на сервер-лидер, в конечном итоге были зафиксированы всеми серверами, и убедиться, что транзакции, отправленные только на сервере-лидере, отбрасываются.
3.5 Механизм кворума NWR
Кворум NWR: механизм кворума обычно используется в распределенных сценариях для обеспечения безопасности данных и реализации окончательного согласованного алгоритма голосования в распределенной среде. Основным принципом этого алгоритма происходит от принципа голубя. Его самое большое преимущество состоит в том, что оно может не только добиться сильной последовательности, но и настроить уровень согласованности.
Принцип голубя, и принцип ящика 名狄利克雷, принцип голубя.
Одно из простых выражений: Если есть n клеток и n+1 голубей, и все голуби содержатся в клетках для голубей, то хотя бы в одной клетке есть как минимум 2 голубя.
Другой: если есть n клеток и k+1 голубей, и все голуби содержатся в клетках для голубей, то по крайней мере в одной клетке есть по крайней мере k+1 голубей.
Зачем начинать с принципа ящика? Во-первых, это всем знакомо и понятно, а во-вторых, действует так же, как и механизм кворума. Принцип ящика, 2 ящика вмещают до 2 яблок в каждом ящике.Теперь яблок 3, как бы они ни были расставлены, в одном из ящиков обязательно будет 2 яблока. Потом меняем принцип ящика.В одном из 2-х ящиков 2 красных яблока,а в другом 2 зеленых яблока.Вынимаем 3 яблока.Как бы мы их не брали,по крайней мере одно из них красное яблоко,что очень легко понять. Мы рассматриваем красные яблоки как обновленные достоверные данные, а зеленые яблоки — как необновленные недействительные данные. Видно, что мы можем получить достоверные данные, не обновляя все данные (не все красные яблоки), конечно, нам нужно прочитать несколько копий (вынуть несколько яблок).
Возвращаясь к механизму Quorum NWR, что означает NWR?
N: количество реплицированных узлов, то есть количество сохраняемых копий части данных. W: количество узлов, для которых операция записи прошла успешно, то есть количество реплик, для которых каждая запись данных прошла успешно. W должен быть меньше или равен N. R: Минимальное количество узлов, необходимое для операции чтения для получения последней версии данных, то есть, по крайней мере, количество реплик, которые должны быть прочитаны для каждого успешного чтения.
Резюме: Эти три фактора определяют доступность,последовательностьиДопуск перегородки. Пока это гарантировано (W + R > N), последние данные могут быть прочитаны, а уровень согласованности данных может достигать строгой согласованности в соответствии с ограничениями количества копий чтения и записи!
Обсуждение делится на следующие три случая: посылка, когда N фиксировано.
W = 1, R = N，Write Once Read All
В распределенной среде запишите копию, затем, если вы хотите прочитать последние данные, вы должны прочитать все узлы, а затем взять последнюю версию значения. Операции записи эффективны, но операции чтения неэффективны. Высокая согласованность, плохая устойчивость к разделам и низкая доступность
R = 1, W = N, Read Only Write All
В распределенной среде все узлы синхронизируются до того, как их можно будет прочитать, поэтому, пока читается любой узел, могут быть прочитаны самые последние данные. Операции чтения эффективны, но операции записи неэффективны. Отказоустойчивость раздела хорошая, непротиворечивость плохая, реализация сложнее, а доступность высокая
W = Q, R = Q where Q = N/2 + 1
Можно просто понимать как более половины узла записи, узел чтения узел более половины, для получения баланса производительности чтения и записи. Подходит для общего применения для удаления баланса между производительностью чтения и записи. N = 3, W = 2, R = 2, толерантность разбиения разбиения, доступность, соответствие для удаления баланса. Zookeeper так предназначен для
Что нужно добавить, так это то, что ZooKeeper не реализует клиент для чтения более половины узла, поэтому это данные, которые не являются последним завершением синхронизации, но вероятность меньше. Узлы без синхронного завершения — это собственно то, что клиент тоже негатив, потому что будь то проблема сети или проблема машины, Лидер отправляет данные, а клиент точно не может их подключить. Если у вас просто есть доступ к промежуточному статусу клиента в данных синхронизации, то это тоже возможно решить.
3.6 Теория CAP
Теория CAP: впервые была предложена в июле 2000 года. Теория CAP говорит нам, что распределенная система не может одновременно удовлетворять трем требованиям C, A и P.
C: Согласованность, строгая согласованность, множественные копии данных в распределенной среде непротиворечивы. A: Доступность, высокая доступность, услуги, предоставляемые системой, должны быть всегда доступны, а результаты всегда могут быть возвращены в течение ограниченного времени для каждого запроса операции пользователя. P: Partition Tolerance Отказоустойчивость раздела, распределенная система по-прежнему должна иметь возможность предоставлять внешние услуги, которые соответствуют согласованности и доступности при возникновении любого сбоя сетевого раздела.
Поскольку распределенная система не может одновременно удовлетворять трем требованиям C, A и P, нам приходится выбирать между нашими требованиями.
Отказ от P: Самый простой экстремальный подход — разместить его на одном узле, а значит, есть только одна копия данных, а все операции чтения и записи сосредоточены на одном сервере, у которого проблема с единой точкой отказа. Отказ от P также означает отказ от масштабируемости системы, поэтому распределенные системы обычно гарантируют P.
Отказ A: как только система сталкивается с сетевым разделом или другим сбоем, служба должна ждать в течение определенного периода времени, и служба не может быть предоставлена в обычном режиме в течение времени ожидания, то есть служба недоступна.
Отказ от C: На самом деле отказ от согласованности означает отказ от строгой согласованности данных и сохранение согласованности в конечном итоге.Сколько времени потребуется для достижения синхронизации данных, зависит от конструкции системы хранения.
CAP может выбрать только 2 из 3, потому что в распределенной системе обязательно необходима отказоустойчивость P, поэтому на данный момент есть только две ситуации: проблемы в сети приводят либо к возврату ошибки, либо к блокировке ожидания, первая жертвует согласованностью, а вторая последнее, что приносит в жертву удобство использования. Например, HBase — для согласованности данных, а Cassandra — для доступности.
Резюме опыта:
1、不要花费精力浪费在设计同时满足CAP的分布式系统
2、分区容错性往往是分布式系统必然要面对和解决的问题。所以应该把精力放在如何根据业务特点在A和C之间寻求平衡。
3、对于单机软件，因为不用考虑P，所以肯定是 CA 型，比如 MySQL
4、对于分布式软件，因为一定会考虑P，所以又不能兼顾A和C的情况下，只能在A和C做权衡，
比如 HBase, Redis 等。做到服务基本可用，并且数据最终一致即可。
Так родилась теория BASE.
3.7 БАЗОВАЯ теория
В большинстве случаев мы не обязательно требуем сильной согласованности, и некоторые бизнесы могут допустить определенную степень согласованности задержки, поэтому для учета эффективности была разработана теория конечной согласованности BASE, которая была предложена архитектором из eBay. Полное название БАЗОВОЙ теории: полное название: В основном доступный (в основном доступный), Мягкое состояние (мягкое состояние) и В конечном счете непротиворечивый (эвентуальная согласованность) Аббревиатура из трех фраз. Основная идея заключается в следующем: даже если невозможно добиться строгой согласованности, каждое приложение может использовать соответствующий метод для достижения окончательной согласованности в соответствии со своими бизнес-характеристиками. Одним словом, не впадайте в крайности: ОСНОВАНИЕ — это результат взвешивания С и А в теории CAP.
Не сильная последовательность, а окончательная последовательность. Не высокая доступность, а базовая доступность.
В основном доступный: в основном доступный означает, что при сбое распределенной системы часть доступности может быть потеряна, т.е.Гарантированная доступность ядра
Например, Taobao Double 11, чтобы защитить стабильность системы, заказывайте в обычном режиме, а другие пограничные услуги могут быть временно недоступны. В настоящее время допускается простой некоторых непрофильных сервисов.
Мягкое состояние: Мягкое состояниеОтносится к разрешению существования системы в промежуточном состоянии., и это промежуточное состояние не влияет на общую доступность системы. Как правило, в распределенном хранилище имеется как минимум три копии фрагмента данных, и задержка при разрешении синхронизации копий между разными узлами является воплощением мягкого состояния. С точки зрения непрофессионала:Задержка при данных узла синхронизации позволяет наличию разныхИ нет промежуточного состояния, в котором задержка синхронизации данных не влияет на общую производительность системы.
В конечном итоге согласованность: в конечном счете согласованность относится ко всем копиям данных в системе.Через определенный промежуток времени, наконец, может быть достигнуто согласованное состояние.. Слабая согласованность противоположна сильной согласованности, а окончательная согласованность — это частный случай слабой согласованности, требующий окончательной согласованности, а не строгой согласованности в реальном времени.
Finally
В общем, мы упомянули анализ централизованной и распределенной архитектуры развертывания сервисов, а также различные трудности, возникающие при проектировании распределенных систем: проблема непротиворечивости данных
2PC и 3PC - это общий способ достижения цели, но все же есть недостатки. Paxos Raft ZAB даже сложные проблемы, связанные с появлением распределенных сетей, таких как нарушение связи, эти алгоритмы могут обеспечить согласованность
Кворум парламентских механизмов СЗР: Р + Ж> Н ===> большинство
Конфликт для консистенции и доступности, CAP и основание: распределенные системы должны удовлетворять P, а также могут сделать только компромиссы в C и A
Большинство систем являются БАЗОВЫМИ системами (в основном доступными + в конечном итоге согласованными)