Спецификация XA
XA — это спецификация интерфейса (то есть функция интерфейса) между транзакционным промежуточным ПО и базой данных, определённой X/Open DTP, которая используется транзакционным промежуточным ПО для уведомления базы данных о начале, завершении, коммите, откате и т. д. транзакций. Функции интерфейса XA предоставляются поставщиками баз данных.
Соглашение о подаче заявок второго порядка и соглашение о подаче заявок третьего порядка были вытеканы из этой идеи. Можно сказать, что двухэтапные коммиты на самом деле являются ключом к реализации распределённых транзакций XA (точнее: двухступенчатые коммиты в основном обеспечивают атомичность распределённых транзакций: то есть все узлы либо делают всё, либо не выполняют ничего)
2PC
Двухфазный коммит — это алгоритм, разработанный для поддержания согласованности транзакцийных коммитов для всех узлов на основе распределённой системной архитектуры в области компьютерных сетей и баз данных. Часто двухступенчатый фикс также называют протоколом. В распределённой системе каждый узел может знать успех или неудачу своей операции, но не может знать успех или неудачу операций других узлов. Когда транзакция охватывает несколько узлов, чтобы сохранить характеристики ACID, необходимо ввести компонент, выступающий в роли координатора, который контролирует результаты всех узлов (называемых участниками) и в конечном итоге инструктирует эти узлы отправлять результаты (например, записывать обновлённые данные на диск и т.д.). Таким образом, идею алгоритма двухэтапной подачи можно резюмировать следующим образом: участники уведомят координатора об успехе или неудаче операции, а затем координатор решит, сдать ли операцию или отменить операцию на основе обратной связи всех участников.
Так называемые два этапа: первый этап — этап подготовки (этап голосования) и второй этап — этап сдачи (этап исполнения).
Этап подготовки
Координатор транзакций (менеджер транзакций) отправляет каждому участнику сообщение «Подготовить» (менеджеру ресурсов), и каждый участник либо напрямую возвращает ошибку (например, неудачную проверку разрешения), либо выполняет транзакцию локально, записывает локальные журналы повторения и отмены, но не коммитирует и достигает состояния «всё готово, только восточный ветер должен».
Этап подготовки можно дополнительно разделить на следующие три этапа:
1) Координатор-узел спрашивает все участвующие узлы, могут ли они провести голосование, и начинает ждать ответа от каждого узла-участника.
2) Участвующий узел выполняет все операции транзакций до начала запроса и записывает информацию об отмене и повторе в журнал. (Примечание: если операция успешна, каждый участник уже выполнил операцию транзакции)
3) Каждый участник-узел отвечает на запрос, инициированный координатором. Если операция транзакции участвующего узла действительно успешно выполнена, она возвращает сообщение «Согласен»; Если операция транзакции узла-участника действительно не работает, она возвращает сообщение «прерванно».
Стадия сдачи
Если координатор получает сообщение о неудаче или тайм-аут от участника, он отправляет сообщение о откате напрямую каждому участнику. В противном случае отправьте сообщение Commit; Участники выполняют операции фиксации или отката в соответствии с инструкциями координатора, чтобы освободить все ресурсы блокировки, используемые в процессе транзакции. (Примечание: ресурсы блокировки должны быть освобождены на финальном этапе)
Далее процесс подачи рассматривается отдельно в двух случаях.
Когда соответствующее сообщение, полученное координационным узлом от всех узлов-участников, равно Согласно:
Стадия сдачи
Если координатор получает сообщение о неудаче или тайм-аут от участника, он отправляет сообщение о откате напрямую каждому участнику. В противном случае отправьте сообщение Commit; Участники выполняют операции фиксации или отката в соответствии с инструкциями координатора, чтобы освободить все ресурсы блокировки, используемые в процессе транзакции. (Примечание: ресурсы блокировки должны быть освобождены на финальном этапе)
Далее процесс подачи рассматривается отдельно в двух случаях.
Когда соответствующее сообщение, полученное координационным узлом от всех узлов-участников, равно Согласно:
1) Координатор-узел отправляет запрос «коммит» всем учащим узлам.
2) Участвующий узел официально завершает операцию и освобождает ресурсы, занятые на протяжении всего периода транзакции.
3) Участвующий узел отправляет сообщение «Готово» координатору.
4) Координатор-узел завершает транзакцию после получения обратной связи «Сделано» от всех узлов-участников.
1) Координатор-узел отправляет запрос на «откат» всем учащим узлам.
2) Узел участника использует ранее записанную информацию об отмене для отката и освобождения ресурсов, занятых в течение всего периода транзакции.
3) Узел участника отправляет сообщение «откат завершен» узлу координатора.
4) Координирующий узел отменяет транзакцию после получения обратной связи «Rollback Complete» от всех узлов-участников.
Коммиты фазы 2, похоже, обеспечивают атомарные операции, но, к сожалению, у коммита второго этапа есть несколько недостатков:
1. Проблема синхронного блокирования. Во время выполнения все участвующие узлы блокируют транзакции. Когда участник занимает публичный ресурс, другие сторонние узлы должны быть заблокированы от доступа к нему.
2. Единственная точка отказа. Из-за важности координатора, как только координатор не справляется. Участники продолжат блокировать блокировку. Особенно на втором этапе, если координатор не срабатывает, все участники всё ещё находятся в состоянии блокировки ресурсов транзакций и не могут продолжать выполнять операции транзакции. (Если координатор положил трубку, вы можете переизбрать координатора, но это не решит проблему, что участник заблокирован из-за отсутствия координатора)
3. Несогласованность данных. На втором этапе второго этапа коммита, когда координатор отправляет запрос на коммит участнику, возникает исключение локальной сети или координатор не выполняет процесс коммита, из-за чего только некоторые участники принимают запрос на коммит. После получения коммит-запроса эти участники выполняют операцию фиксации. Однако другие машины, не получающие коммит-запрос, не могут выполнить этот коммит. В результате согласованность отделов данных происходит во всей распределённой системе.
4. Задачи, которые невозможно решить на втором этапе: координатор падает после отправки коммита, и единственный участник, получивший это сообщение, тоже падает вниз. Таким образом, даже если фасилитатор изберет нового фасилитатора по избирательному соглашению, статус сделки остаётся неопределённым, и никто не знает, была ли она подана.
3PC
Трёхфазный фикс, также известный как трёхфазный протокол фиксации, является усовершенствованной версией двухфазного фикса (2PC).
В отличие от двухступенчатых коммитов, в трёхступенчатых коммитах есть два изменения.
1. Введите механизм тайм-аута. Одновременно у фасилитатора и участников вводится механизм тайм-аута.
2. Вставить подготовительный этап на первом и втором этапах. Это обеспечивает стабильность состояния всех участвующих узлов до финального этапа фиксации.
Другими словами, помимо введения механизма тайм-аута, 3PC вновь делит этап подготовки 2PC на два, так что в трёх этапах коммита есть три этапа: CanCommit, PreCommit и DoCommit.
Этап CanCommit
Этап CanCommit в 3PC на самом деле очень похож на этап подготовки в 2PC. Координатор отправляет заявку на коммит участнику, который возвращает ответ «Да», если он может это сделать, или ответ «Нет».
1. Запрос по транзакции Фасилитатор отправляет участнику запрос на CanCommit. Спросите, можно ли выполнить операцию транзакционного фикса. Затем начинайте ждать ответа участников.
2. Обратная связь После получения запроса CanCommit участник вернёт ответ «Да» и войдёт в состояние готовности, если считает, что транзакция может пройти гладко. В остальном обратная связь — нет.
Фаза до Commit
Фасилитатор решает, запоминать ли операцию PreCommit транзакции, исходя из ответа участника. В зависимости от ответа есть два варианта.
Если обратная связь, которую фасилитатор получает от всех участников, — это ответ «Да», то предварительное выполнение сделки выполняется.
1. Отправить запрос на предварительное согласие Фасилитатор отправляет запрос на предварительное согласие участнику и переходит к этапу подготовки.
2. Предварительная фиксация транзакции После получения запроса на предварительное согласование участник выполняет операцию транзакции и записывает информацию об отмене и повторном выполнении в журнале транзакций.
3. Обратная связь от ответа Если участник успешно выполнит операцию транзакции, ответ ACK возвращается при ожидании финальной инструкции.
1. Отправить запрос на прерывание Фасилитатор отправляет запрос на отмену всем участникам.
2. Прервать транзакцию После того как участник получает запрос ABORT от координатора (или после истечения тайм-аута запрос от координатора не был получен), прерывание транзакции выполняется.
Этот этап коммита по реальной транзакции также можно разделить на следующие две ситуации.
Выполнить коммит
1. Отправить запрос на коммит. Координация получает ответ ACK, отправленный участником, затем он переходит из состояния до коммита в состояние коммита. и отправить запрос на doCommit всем участникам.
2. Отправка транзакции После получения запроса doCommit участник выполняет формальный коммит транзакции. и освободить все ресурсы транзакций после завершения коммита транзакции.
3. Ответить на отзывы После отправки сделки отправьте координатору ответ в формате Ack.
4. Завершить транзакцию После того как координатор получает ответ ACK от всех участников, транзакция завершается.
Если координатор не получает ответ ACK от участника (это может быть не ответ ACK от получателя или ответ может истечь времени), транзакция прерывания выполняется.
1. Отправить запрос на прерывание Фасилитатор отправляет запрос на отмену всем участникам
2. Откат транзакции После получения запроса ABORT участник использует информацию об отмене, записанную в фазе 2, для выполнения операции отката транзакции и освобождает все ресурсы транзакции после завершения отката.
3. Результаты обратной связи После завершения отката транзакции участником отправьте ACK-сообщение координатору
4. Прервать транзакцию После того как координатор получает сообщение ACK от участника, транзакция прерывается.
Разница между 2PC и 3PC
По сравнению с 2PC, 3PC в основном решает проблему единой точки отказа и снижает блокировку, потому что, если участник не успевает вовремя получить сообщение от координатора, он по умолчанию выполняет коммит. Вместо того чтобы постоянно хранить транзакционные ресурсы и находиться в состоянии блокировки. Однако этот механизм также вызывает проблемы с согласованностью данных, поскольку ответ на прекращение, отправленный координатором, не получается участником вовремя по сетевым причинам, после чего участник выполняет операцию фиксации после ожидания тайм-аута. Это создаёт несоответствие данных с другими участниками, которые получают команду отмены и выполняют откат.
|
Опубликовано 17.03.2021 10:15:10
|
|
|
