Оригинальная ссылка:БЛОГ Ранний Ван / 2018/06-DIS ...

Теория распределенных систем

Теорема CAP

Теорема CAPУказано, что для распределенной системы невозможно одновременное выполнение следующих трех пунктов:

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

В распределенной системе сеть, состоящая из узлов, должна быть связана. Однако из-за некоторых сбоев или задержек некоторые узлы отключаются, и вся сеть делится на несколько областей. Данные разбросаны по этим несвязанным областям, которые называются разделами. Когда вы сохраняете элемент данных только в одном узле, после появления раздела та часть, которая не подключена к этому узлу, не сможет получить доступ к данным. Разделение на данный момент недопустимо. Способ улучшить устойчивость к разделению состоит в том, чтобы скопировать элемент данных на несколько узлов.После того, как произойдет разделение, элемент данных может быть распределен по каждой области, и устойчивость улучшится. Однако копирование данных на несколько узлов приведет к проблемам с согласованностью, то есть данные на нескольких узлах могут быть несогласованными. Чтобы обеспечить согласованность, каждая операция записи должна ждать, пока все узлы успешно запишутся, и это ожидание приведет к проблемам с доступностью. Как правило, чем больше узлов, на которых существуют данные, тем выше устойчивость к разделению, но чем больше данных нужно реплицировать и обновлять, тем сложнее обеспечить согласованность. Чтобы обеспечить согласованность, чем больше времени требуется для обновления всех данных узла, тем ниже доступность — ответ от Zhihu Wu Jiang.

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

СУРБД: система управления реляционными базами данных, система управления реляционными базами данных.

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

• CA: одноточечный кластер, система, удовлетворяющая требованиям согласованности и доступности, обычно не очень мощная с точки зрения масштабируемости.
• CP: последовательные, устойчивые к разделам системы, обычно не очень высокая производительность.
• AP: Система, которая удовлетворяет требованиям доступности и устойчивости к разделам, обычно может иметь более низкие требования к согласованности.

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

Распределенный: разные сервисные модули развернуты на разных серверах, и они взаимодействуют и вызывают через Rpc/HTTP и другие методы для предоставления внешних услуг и совместной работы внутри группы.

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

Кислота и основание

ACID

ACIDОтносится к четырем характеристикам транзакционных операций в традиционных базах данных:

• Атомарность: все операции в транзакции, как базовой единице, либо полностью завершены, либо не завершены, и не будут заканчиваться определенной ссылкой в ​​середине. Если во время выполнения транзакции возникает ошибка, она будет отброшена (Rollback) к состоянию до начала транзакции, как будто транзакция никогда не выполнялась.
• Непротиворечивость: целостность базы данных не нарушается до начала транзакции и после ее завершения. Транзакция может правильно преобразовать базу данных из одного согласованного состояния в другое согласованное состояние.
• Изоляция: также известная как независимость, способность базы данных позволять нескольким параллельным транзакциям одновременно читать, записывать и изменять свои данные.Изоляция может предотвратить несогласованность данных из-за перекрестного выполнения, когда несколько транзакций выполняются одновременно. Существуют различные уровни изоляции транзакций, включая незафиксированное чтение, зафиксированное чтение, повторяемое чтение и сериализуемый.
• Долговечность: после завершения транзакции изменение данных является постоянным и не будет потеряно даже в случае сбоя системы.

BASE

Теория BASE является расширением теории CAP.Основная идея заключается в том, что, хотя строгой согласованности достичь невозможно, конечную согласованность можно достичь подходящим способом.

БАЗА состоит из трех частей:

• Базовая доступность: в случае отказа распределенной системы частичная доступность может быть потеряна, чтобы обеспечить доступность ядра.
• Мягкое состояние: позволяет системе находиться в промежуточном состоянии, которое не влияет на общую доступность системы. Как правило, в распределенном хранилище имеется как минимум три копии фрагмента данных, и задержка при разрешении синхронизации копий между разными узлами является воплощением мягкого состояния. Асинхронная репликация репликации mysql также является проявлением
• Согласованность в конечном итоге: это означает, что все копии данных в системе могут в конечном итоге достичь согласованного состояния через определенный период времени. Эвентуальная согласованность является частным случаем слабой согласованности.

Разница между двумя

ACID принадлежит CA, которая является общей концепцией проектирования традиционных баз данных и придерживается строгой модели согласованности.

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

Однако в реальных распределенных сценариях разные бизнес-подразделения и компоненты предъявляют разные требования к согласованности данных, поэтому в процессе проектирования архитектуры конкретной распределенной системы характеристики ACID и теория BASE часто используются вместе. Например, он удовлетворяет BASE в целом и ACID частично.

Модель согласованности

• Строгая согласованность: когда операция обновления завершена, любой доступ нескольких последующих процессов или потоков будет возвращать последнее обновленное значение. Это наиболее удобно для пользователя, то есть то, что пользователь написал в прошлый раз, гарантированно будет прочитано в следующий раз. Однако эта реализация оказывает большее влияние на производительность, поскольку означает, что пользователь не может прочитать данные, пока не будет обработана последняя операция.
• Слабая согласованность: система не гарантирует, что доступ процесса или потока вернет последнее обновленное значение. После того, как данные успешно записаны, система не обещает немедленно прочитать вновь записанное значение и не обещает прочитать последнее значение. Однако мы постараемся сделать все возможное, чтобы данные могли достичь согласованного состояния после определенного временного уровня (например, второго уровня).
  • Конечная согласованность: особая форма слабой согласованности. Система гарантирует, что система в итоге вернет значение последней операции обновления без последующих обновлений. Если исходить из того, что сбоев не происходит, на время окна несогласованности главным образом влияют задержка связи, загрузка системы и количество реплик. DNS — это типичная система конечной согласованности.
    • Причинно-следственная согласованность: если процесс A уведомляет процесс B о завершении обновления после обновления, то операция доступа B вернет обновленное значение. Если причинно-следственной связи нет, процесс C будет следовать правилам эвентуальной согласованности.
    • Согласованность чтения-записи: особая форма причинно-следственной согласованности. Процесс всегда может прочитать свои собственные обновленные данные
    • Согласованность сеанса: особая форма согласованности чтения-записи. Когда процесс обращается к системе хранения в том же сеансе, система гарантирует, что процесс читает то, что он пишет.
    • Консистенция монотонного чтения: если процесс прочитал определенное значение, то этот процесс не будет читать какое-либо значение из более старой версии этого значения.
    • Монотонная согласованность записи: система гарантирует сериализацию операций записи в один и тот же процесс.

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

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

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

Теорема о невозможности ФЛП

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

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

Доказательство невозможности FLP

Распределенная транзакция

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

DRDA: архитектура распределенной реляционной базы данных, архитектура распределенной реляционной базы данных

Спецификация XA

Спецификация XA — это спецификация обработки для модели распределенной обработки транзакций (DTP), разработанная организацией X/Open (теперь Open Group).

Модель DTP включаетТочка доступа приложения,Менеджер транзакций ТМ,Менеджер ресурсов RM,Коммуникационный обозреватель CRMЧетыре части. Общий менеджер транзакций TM является промежуточным программным обеспечением транзакций, общий менеджер ресурсов RM является базой данных, а общий диспетчер коммуникационных ресурсов CRM является промежуточным программным обеспечением сообщений. ПО промежуточного слоя транзакции требуется для уведомления и координации фиксации или отката соответствующей базы данных.

Спецификация описывает интерфейс между глобальным диспетчером транзакций и локальным диспетчером ресурсов. Цель спецификации XA — разрешить доступ к нескольким ресурсам (таким как базы данных, серверы приложений, очереди сообщений и т. д.) в рамках одной транзакции, чтобы свойства ACID оставались действительными для разных приложений.

XA использует двухфазную или трехэтапную фиксацию, чтобы гарантировать, что все ресурсы фиксируют или откатывают любую конкретную транзакцию одновременно.

Двухфазная фиксация — 2 шт.

Когда транзакция охватывает несколько узлов, для поддержания ACID-характеристик транзакции необходимо ввести компонент в качестве координатора для унифицированного управления результатами операций всех узлов (называемых участниками) и, наконец, указать этим узлам, следует ли выполнять фактические результаты операции. такДвухэтапная фиксацияИдея алгоритма может быть резюмирована следующим образом: участники уведомляют координатора об успехе или неудаче операции, а затем координатор решает, хочет ли каждый участник выполнить операцию или прервать операцию на основе информации обратной связи всех участников.

Условия, необходимые для двухэтапной фиксации:

1. В распределенной системе один узел выступает в качестве координатора (Coordinator), другие узлы являются участниками (когортами) и могут обмениваться данными между узлами сети.
2. Все узлы используют журналы с упреждающей записью, а журналы хранятся на надежном устройстве хранения после записи, даже если узел поврежден, данные журнала не исчезнут.
3. Все узлы не повреждаются безвозвратно и могут быть восстановлены даже после повреждения

Два этапа:

1. Подготовительный этап (этап голосования)
2. фаза фиксации (этап выполнения)

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

1. Координатор транзакций (менеджер транзакций) отправляет сообщение Prepare каждому участнику (менеджеру ресурсов), спрашивая, можно ли выполнить операцию фиксации, и начинает ждать ответа каждого узла-участника.
2. Участники выполняют операции с транзакциями и записывают в журнал информацию об отмене и повторении операций.
3. Каждый узел-участник отвечает на запрос, инициированный узлом-координатором. Если транзакционная операция узла-участника действительно успешна, он возвращает сообщение «соглашение»; если транзакционная операция узла-участника фактически терпит неудачу, он возвращает сообщение «Прервать».

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

этап фиксации

• Когда узел-координатор получает ответные сообщения «Согласовано» от всех узлов-участников
  1. Узел-координатор отправляет запрос «формальной фиксации» всем узлам-участникам.
  2. Узел-участник официально завершает операцию и освобождает ресурсы, занятые в течение всего периода транзакции.
  3. Узел-участник отправляет сообщение «Готово» узлу-координатору.
  4. Узел-координатор завершает транзакцию после получения сообщения «Готово» от всех узлов-участников.

• Если ответное сообщение, возвращенное любым узлом-участником на первом этапе, имеет значение «Прервано» или узел-координатор не может получить ответное сообщение от всех узлов-участников до истечения времени ожидания запроса на первом этапе.
  1. Узел-координатор отправляет запрос «операции отката» всем узлам-участникам.
  2. Узел-участник использует ранее записанную информацию об отмене для выполнения отката и освобождения ресурсов, занятых в течение всего периода транзакции.
  3. Узел-участник отправляет сообщение «откат завершен» узлу-координатору.
  4. После того, как узел-координатор получает сообщение «откат завершен» от всех узлов-участников, он отменяет транзакцию.

Независимо от конечного результата, вторая фаза завершает текущую транзакцию.

дефект

1. Проблема блокировки синхронизации. Во время выполнения все участвующие узлы блокируют транзакции. Когда участник занимает общедоступный ресурс, другие сторонние узлы будут заблокированы при доступе к общедоступному ресурсу.

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

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

4. Есть неразрешимая проблема с двухфазным коммитом:

Для существующих моделей возможные ошибки и соответствующие меры следующие:

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

Подробное описание третьего вопроса выглядит следующим образом:

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

• До того, как RM3 зависнет, независимо от того, получена команда или нет, до тех пор, пока транзакционная операция не будет выполнена, это не повлияет на окончательную согласованность, потому что, когда RM3 зависает, но его транзакция не выполнила окончательную фиксацию или откат, новая координатор и другие обычные узлы. Независимо от того, был ли он зафиксирован или отменен, пока RM3 восстанавливается, новому координатору предлагается выполнить те же действия для обеспечения глобальной согласованности.
• Серьезная проблема в том, что финальная операция транзакции выполняется до того, как зависший RM3 зависнет:
  • Координатор зависает после отправки инструкции на втором этапе, и RM3 тоже зависает после получения этой инструкции и работы с ним.Когда появляется новый координатор, никто не знает, что первоначальный координатор отправил Commit.Это все еще Rollback, и неясно, выполнил ли RM3 коммит или откат, после появления нового координатора он спросит статус каждой ноды Если нода ответит Нет, то пошлет команду отката Если все ноды ответят Да, пошлет Коммит команда; например, новый координатор и другие обычные узлы на приведенном выше рисунке должны успешно проголосовать, а затем выполнить команду Commit, и после того, как RM3 вернется в нормальное состояние, трудно определить, является ли целое согласованным, потому что RM3 может ответить Abort на первом этапе, а затем первоначальный координатор отправил откат, и RM3 был откатан перед зависанием, поэтому глобальная ситуация в настоящее время несовместима (несогласованный RM3 должен быть восстановлен до согласованности с помощью других методов в это время, но система в целом несостоятельна до завершения)

Последняя проблема заключается в том, что 2PC не может ее решить, но 3PC может решить ее в определенной степени.

Трехфазная фиксация — 3 шт.

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

1. Внедрить механизм тайм-аута. При этом как у координатора, так и у участников вводится механизм тайм-аута (только у 2PC механизм тайм-аута задается координатором). заблокирован на долгое время.
2. Вставьте этап подготовки между первым и вторым этапом. Гарантируется, что состояние каждого участвующего узла будет согласованным перед финальной фазой фиксации.

Есть три этапа:

1. CanCommit
2. PreCommit
3. DoCommit

CanCommit

1. Координатор отправляет участнику запрос CanCommit. Спросите, можно ли выполнить операцию фиксации транзакции. Затем начните ждать ответа участника
2. После того, как участник получит запрос CanCommit, при нормальных обстоятельствах, если он считает, что транзакция может быть успешно выполнена, он вернет ответ «Да» и перейдет в состояние готовности. В противном случае отзыв Нет

PreCommit

• Если координатор получает ответ Да от всех участников, то выполняется предварительное выполнение транзакции:
  1. Отправка запроса на предварительную фиксацию Координатор отправляет участнику запрос на предварительную фиксацию и переходит в стадию «Подготовлено»
  2. После того, как участник предварительной фиксации транзакции получит запрос PreCommit, он выполнит операцию транзакции и запишет информацию об отмене и повторении в журнале транзакций.
  3. Если участник успешно выполняет транзакционную операцию, он возвращает ответ ACK и начинает ждать финальной команды.

На этом рисунке, если сообщение PreCommit не приходит или время ожидания истекло, RM должен прервать свою собственную локальную транзакцию, точно так же, как тайм-аут Abort на рисунке ниже.

• Если какой-либо участник отправляет координатору ответ No или после ожидания таймаута координатор не получает ответа от участника, то транзакция прерывается:
  1. Отправить запрос на прерывание Координатор отправляет всем участникам запрос на прерывание
  2. После того, как участник получает от координатора запрос Abort (или по истечении тайм-аута координатор все-таки получен), выполняется прерывание транзакции.

DoCommit

По делу делится на два сценария:

• После нормального ответа выполните операцию фиксации для завершения транзакции:
  1. Координатор получает ответ ACK, отправленный участником в фазе PreCommit, затем он войдет в состояние фиксации из состояния pre-commit, и отправит запрос DoCommit всем участникам
  2. После того, как участник получает запрос DoCommit, он выполняет формальную фиксацию транзакции и освобождает все ресурсы транзакции после завершения фиксации транзакции.
  3. После того, как транзакция зафиксирована, отправьте ответ ACK координатору.
  4. После того, как координатор получает ответы ACK от всех участников, транзакция завершается.

• Координатор ACK не получен в ответ на отправленные участники (вероятно, не получатель отправить ответ ACK, он может отвечать на тайм-аут), он выполнит транзакцию прерывания:
  1. Координатор отправляет всем участникам запрос на прерывание.
  2. После того как участник получает запрос на отмену, он использует информацию об отмене, записанную на этапе 2, для выполнения операции отката транзакции и освобождает все ресурсы транзакции после завершения отката.
  3. После того, как участник завершает откат транзакции, он отправляет ACK-сообщение координатору
  4. После того, как координатор получает сообщение ACK, возвращенное участником, он завершает транзакцию.

На рисунке RM3 нормально не отвечает на ACK на втором этапе, что может быть следующим:

• Например, RM3 не получает сообщение PreCommit нормально, а отменяет локальную транзакцию на втором этапе, поэтому ACK не возвращается, тогда при получении Abort на третьем этапе ничего делать не нужно
• Также возможно, что RM3 получил сообщение PreCommit и выполнил операцию транзакции, но сообщение ACK было отправлено с опозданием, тогда третий этап получения Abort также выполнил такой же откат Undo, как и другие узлы.
• Если это второй этап, то RM3 зависает, если стойкий, то зависает.На этом этапе игнорируйте его и делайте синхронизацию данных после его восстановления, если он восстанавливается после того, как он завис, вам нужно спросить статус транзакции TM чтобы определить, следует ли отменить локальную транзакцию или продолжить выполнение транзакции

На третьем этапе, еслиучастникЕсли запрос DoCommit или Abort от координатора не может быть получен вовремя,После ожидания тайм-аута транзакция будет по-прежнему зафиксирована

В этом есть определенная сложность, поскольку возможность входа на третий этап означает, что координатор должен инициировать запрос PreCommit на втором этапе, а предпосылка инициирования запроса PreCommit состоит в том, что все участники первого этапа ответил Да, что говорит о том, что у всех участников Состояние участников на тот момент было оптимистичным, то у участников третьего этапа даже не былововремяПосле получения запроса DoCommit от координатора, он также продолжает завершать отправку локальной транзакции, поэтому вероятность завершения глобальной транзакции все еще очень высока, что направлено на проблему несогласованности данных 2PC

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

дефект

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

Что касается вышеупомянутых проблем, которые не может решить 2PC, то как их решает 3PC?

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

• Если это также координатор второго этапа и RM3 кладет трубку

На самом деле, пока никакая окончательная фиксация или откат транзакции не повлияют на реализацию конечного результата, пока координатор запроса стоит за восстановлением RM3 и может выполнять ту же операцию

• Если он переходит на третий этап, координатор и RM3 вешают трубку, а RM3 выполняет последнюю операцию.

В это время, после появления нового координатора, вы можете узнать, отправлять ли команду фиксации или отката, проверив состояние нормального узла: если оба находятся в состоянии Commited или PreCommit, результатом первого раунда голосования будет «Да». , иначе невозможно войти в состояние PreCommit, поэтому Новый координатор может отправить команду фиксации; если статус существующей ноды — Cancel, что указывает на то, что первый тур результатов голосования имеет отрицательное голосование, то новый координатор может отправить команда отката. Здесь может возникнуть вопрос.Говоря о DoCommit,мы говорили,что ACK участников второго этапа могут не отвечать координатору нормально.Если RM3 проголосовал за первый раунд поддержки,а потом перешел в состояние PreCommit,то ACK нормально не ответил координатору. , поэтому координатор зависает после отправки команды Abort на RM3, а RM3 тоже зависает после получения команды.В это время RM3 еще будет откатываться, а новый координатор и нормальный нода выполнит подчинение.На самом деле 3PC здесь вроде нет.Однако можно оценить вероятность такой ситуации.Вероятность того,что координатор отправит инструкцию и зависнет а потом некоторые участники тоже зависнут после выполнения низка , и необходимо удовлетворить зависшего координатора после подачи голоса в поддержку.Вероятность того, что координатор отправит команду Abort после таймаута пост-ответа, еще меньше

Понимание 2PC и 3PC

Мы иллюстрируем и понимаем этот процесс на реальном примере:

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

2PC

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

Шаг 2 После того, как пастор прочитает его, если обе стороны напишут «да», то скажите обеим сторонам обменяться жетонами, чтобы показать, что они могут продолжать свою дружбу; если одна из сторон напишет «нет», то скажите обеим сторонам расстаться, и токены также снимаются.

Но здесь 2PC не может решить проблему: если в записке, написанной мужчиной, написано «Нет», а пастор прочитал ее и сказал мужчине, что вы должны снять жетон, вы не подходите, а пастор получил сердечный приступ и был госпитализирован, Получив известие, мужчина также забрал жетон и приготовился расстаться, но мужчина был внезапно избит, госпитализирован и впал в кому; появился новый пастор и продолжил спрашивать мнение женщины, потому что они не Не зная мнения мужчины, это может привести к несчастливым отношениям.

3PC

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

Шаг 2 После прочтения пастырем, если обе стороны напишут «да», то сначала скажите обеим сторонам подготовить жетоны; если одна сторона напишет «нет», то сообщите обеим сторонам, что нет необходимости готовить жетоны; после получения сообщение, обе стороны отвечают, что знают

Шаг 3 После того, как пастор подтвердит ответы обеих сторон, он информирует обе стороны, будут ли они вместе в конце и нужно ли обмениваться жетонами.

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

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

устранять несоответствия

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

Восстановление данных раздела

Для сложного восстановления данных см. Управление версиями SVN, которые могут быть объединены автоматически, или могут возникать конфликты, требующие ручного вмешательства.

Для простого восстановления данных см. Синхронизация master-slave Mysql, данные могут быть автоматически импортированы из главной библиотеки в подчиненную библиотеку.

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

Компенсация сделки раздела

Например, транзакция сообщения MQ и протокол транзакции TCC являются компенсационным механизмом:

• Транзакция MQ: используйте промежуточное программное обеспечение сообщений для асинхронного завершения второй половины транзакции для достижения окончательной согласованности системы.
• Транзакция TCC: TCC — это протокол, предложенный Alibaba, который делит транзакцию на три части: попытка, фиксация и отмена, которые также могут обеспечить окончательную согласованность.

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

• Алгоритм Паксос: согласованный алгоритм, основанный на обмене сообщениями и отказоустойчивых характеристиках.
  • Алгоритм плота: Raft — алгоритм консенсуса для замены Paxos. Цель Raft — предоставить более понятный алгоритм, который, как было показано, обеспечивает такую ​​же отказоустойчивость и производительность, что и Paxos.
  • Zab: Атомарный широковещательный протокол Zookeeper, который является согласованным протоколом, используемым внутри Zookeeper. По сравнению с Paxos, самой большой особенностью Zab является обеспечение строгой согласованности (сильной согласованности или линеаризуемой согласованности).

Reference

• CAP-теория распределенных систем
• Теория CAP
• Глубокое понимание 2PC и 3PC распределенных систем
• «Передовой опыт» обеспечения согласованности распределенных систем на основе служб
• Алгоритмы распределенной согласованности и консенсуса