stringtranslate.com

Двухфазный протокол фиксации

В обработке транзакций , базах данных и компьютерных сетях двухфазный протокол фиксации ( 2PC , tupac ) является типом протокола атомарной фиксации (ACP). Это распределенный алгоритм , который координирует все процессы, участвующие в распределенной атомарной транзакции, относительно того, следует ли фиксировать или отменять (откатывать) транзакцию. Этот протокол (специализированный тип протокола консенсуса ) достигает своей цели даже во многих случаях временного сбоя системы (включая сбои процесса, сетевого узла, связи и т. д.), и поэтому широко используется. [1] [2] [3] Однако он не устойчив ко всем возможным конфигурациям сбоев, и в редких случаях для исправления результата требуется ручное вмешательство. Для обеспечения восстановления после сбоя (автоматического в большинстве случаев) участники протокола используют регистрацию состояний протокола. Записи журнала, которые обычно генерируются медленно, но выдерживают сбои, используются процедурами восстановления протокола . Существует множество вариантов протокола, которые в первую очередь отличаются стратегиями регистрации и механизмами восстановления. Хотя процедуры восстановления обычно предназначены для нечастого использования, они составляют существенную часть протокола, поскольку протокол должен учитывать и поддерживать множество возможных сценариев сбоев.

При «нормальном выполнении» любой отдельной распределенной транзакции (т. е. когда не происходит сбоев, что обычно является наиболее частой ситуацией) протокол состоит из двух фаз:

  1. Фаза запроса на подтверждение (или фаза голосования), на которой процесс-координатор пытается подготовить все участвующие в транзакции процессы (именованные участники, когорты или рабочие) к выполнению необходимых шагов для подтверждения или отмены транзакции и проголосовать либо «Да»: подтверждение (если выполнение локальной части участника транзакции завершилось корректно), либо «Нет»: отмена (если обнаружена проблема с локальной частью), и
  2. Фаза фиксации, в которой на основе голосования участников координатор решает, фиксировать ли (только если все проголосовали «Да») или отменить транзакцию (в противном случае), и уведомляет о результате всех участников. Затем участники выполняют необходимые действия (фиксируют или отменяют) со своими локальными транзакционными ресурсами (также называемыми восстанавливаемыми ресурсами; например, данными базы данных) и соответствующими частями в других выходных данных транзакции (если применимо).

Протокол двухфазной фиксации (2PC) не следует путать с протоколом двухфазной блокировки (2PL), протоколом управления параллелизмом .

Предположения

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

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

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

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

Базовый алгоритм

Фаза запроса на фиксацию (или голосования)

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

Фаза принятия (или завершения)

Успех

Если координатор получил сообщение о согласии от всех участников на этапе запроса на подтверждение:

  1. Координатор отправляет всем участникам сообщение о фиксации.
  2. Каждый участник завершает операцию и снимает все блокировки и ресурсы, удерживаемые во время транзакции.
  3. Каждый участник отправляет подтверждение координатору.
  4. Координатор завершает транзакцию после получения всех подтверждений.

Отказ

Если какой-либо участник голосует «Нет» на этапе запроса на фиксацию (или истекает тайм-аут координатора):

  1. Координатор отправляет всем участникам сообщение об откате.
  2. Каждый участник отменяет транзакцию, используя журнал отмены, и освобождает ресурсы и блокировки, удерживаемые во время транзакции.
  3. Каждый участник отправляет подтверждение координатору.
  4. Координатор отменяет транзакцию после получения всех подтверждений.

Поток сообщений

Координатор Участник ЗАПРОС НА СОВЕРШЕНИЕ --------------------------------> ГОЛОСОВАТЬ ДА/НЕТ подготовить*/отменить* <-------------------------------зафиксировать*/отменить* зафиксировать/откатить --------------------------------> ПОДТВЕРЖДЕНИЕ совершить*/отменить* <-------------------------------- конец

Символ * рядом с типом записи означает, что запись принудительно помещается в стабильное хранилище. [4]

Недостатки

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

Реализация протокола двухфазной фиксации

Общая архитектура

Во многих случаях протокол 2PC распространяется в компьютерной сети. Он легко распространяется путем внедрения нескольких выделенных компонентов 2PC, похожих друг на друга, обычно называемых менеджерами транзакций (TM; также называемых агентами 2PC или мониторами обработки транзакций), которые выполняют выполнение протокола для каждой транзакции (например, X/Open XA от The Open Group ). Базы данных, вовлеченные в распределенную транзакцию, участники, как координатор, так и участники, регистрируются для закрытия TM (обычно находящихся на соответствующих сетевых узлах, что и участники) для завершения этой транзакции с помощью 2PC. Каждая распределенная транзакция имеет специальный набор TM, TM, в которых регистрируются участники транзакции. Лидер, TM координатора, существует для каждой транзакции для координации 2PC для нее, обычно TM базы данных координатора. Однако роль координатора может быть передана другому TM по соображениям производительности или надежности. Вместо того, чтобы обмениваться сообщениями 2PC между собой, участники обмениваются сообщениями со своими соответствующими TM. Соответствующие TM взаимодействуют между собой для выполнения схемы протокола 2PC выше, «представляя» соответствующих участников, для завершения этой транзакции. С этой архитектурой протокол полностью распределен (не нуждается ни в каком центральном компоненте обработки или структуре данных) и масштабируется с числом сетевых узлов (размером сети) эффективно.

Эта общая архитектура также эффективна для распространения других протоколов атомарных обязательств помимо 2PC, поскольку все такие протоколы используют один и тот же механизм голосования и распространения результатов среди участников протокола. [1] [2]

Оптимизация протокола

Были проведены исследования баз данных с целью изучения способов извлечения максимальной выгоды из протокола двухфазной фиксации транзакций при одновременном снижении затрат за счет оптимизации протокола [1] [2] [3] и экономии операций протокола при определенных предположениях о поведении системы.

Предполагаемое прерывание и предполагаемое завершение

Предполагаемое прерывание или предполагаемое подтверждение являются распространенными оптимизациями такого рода. [2] [3] [5] Предположение о результате транзакций, либо подтверждение, либо отмена, может сохранить как сообщения, так и операции регистрации участниками во время выполнения протокола 2PC. Например, при предполагаемом прерывании, если во время восстановления системы после сбоя не обнаружено зарегистрированных свидетельств фиксации некоторой транзакции процедурой восстановления, то она предполагает, что транзакция была отменена, и действует соответствующим образом. Это означает, что не имеет значения, регистрируются ли отмены вообще, и такое протоколирование может быть сохранено при этом предположении. Обычно штраф в виде дополнительных операций выплачивается во время восстановления после сбоя в зависимости от типа оптимизации. Таким образом, лучший вариант оптимизации, если таковой имеется, выбирается в соответствии со статистикой сбоя и результата транзакции.

Протокол двухфазной фиксации дерева

Протокол Tree 2PC [2] (также называемый Nested 2PC или Recursive 2PC) является распространенным вариантом 2PC в компьютерной сети , который лучше использует базовую инфраструктуру связи. Участники распределенной транзакции обычно вызываются в порядке, который определяет древовидную структуру, дерево вызовов, где участники являются узлами, а ребра — вызовами (связями связи). Это же дерево обычно используется для завершения транзакции протоколом 2PC, но в принципе для этого может использоваться и другое дерево связи. В дереве 2PC координатор считается корнем («вершиной») дерева связи (перевернутого дерева), в то время как участники — другими узлами. Координатором может быть узел, который инициировал транзакцию (вызываемый рекурсивно (транзитивно) другими участниками), но также другой узел в том же дереве может взять на себя роль координатора вместо этого. Сообщения 2PC от координатора распространяются «вниз» по дереву, в то время как сообщения координатору «собираются» участником у всех участников ниже его, прежде чем он отправит соответствующее сообщение «вверх» по дереву (за исключением сообщения об отмене, которое распространяется «вверх» сразу после его получения или если текущий участник инициирует отмену).

Протокол динамической двухфазной фиксации (Dynamic two-phase commitment, D2PC) [2] [6] является вариантом Tree 2PC без предопределенного координатора. Он включает в себя несколько оптимизаций, которые были предложены ранее. Сообщения о согласии (голоса «Да») начинают распространяться со всех листьев, каждый лист, когда завершает свои задачи от имени транзакции (становится готовым). Промежуточный (не листовой) узел отправляет готовое сообщение о согласии последнему (единственному) соседнему узлу, от которого сообщение о согласии еще не было получено. Координатор определяется динамически путем гонки сообщений о согласии по дереву транзакций, в месте, где они сталкиваются. Они сталкиваются либо в узле дерева транзакций, чтобы стать координатором, либо на ребре дерева. В последнем случае один из двух узлов ребра выбирается в качестве координатора (любой узел). D2PC является оптимальным по времени (среди всех экземпляров определенного дерева транзакций и любой конкретной реализации протокола Tree 2PC; все экземпляры имеют одно и то же дерево; каждый экземпляр имеет другой узел в качестве координатора): выбрав оптимального координатора, D2PC фиксирует как координатора, так и каждого участника за минимально возможное время, позволяя как можно скорее освободить заблокированные ресурсы у каждого участника транзакции (узла дерева).

Смотрите также

Ссылки

  1. ^ abc Филип А. Бернстайн , Вассос Хадзилакос, Натан Гудман (1987): Управление параллельным доступом и восстановление в системах баз данных, Глава 7, Addison Wesley Publishing Company, ISBN  0-201-10715-5
  2. ^ abcdef Герхард Вейкум , Готфрид Воссен (2001): Транзакционные информационные системы, глава 19, Elsevier, ISBN 1-55860-508-8 
  3. ^ abc Филип А. Бернстайн, Эрик Ньюкомер (2009): Принципы обработки транзакций, 2-е издание, архивировано 07.08.2010 в Wayback Machine , Глава 8, Morgan Kaufmann (Elsevier), ISBN 978-1-55860-623-4 
  4. ^ C. Mohan , Bruce Lindsay и R. Obermarck (1986): "Управление транзакциями в системе управления распределенной базой данных R*", ACM Transactions on Database Systems (TODS) , том 11, выпуск 4, декабрь 1986 г., страницы 378–396
  5. ^ C. Mohan , Bruce Lindsay (1985): «Эффективные протоколы фиксации для модели дерева процессов распределенных транзакций», ACM SIGOPS Operating Systems Review , 19(2), стр. 40-52 (апрель 1985 г.)
  6. ^ Йоав Раз (1995): «Протокол динамического двухфазного обязательства (D2PC)», Теория баз данных — ICDT '95 , Конспект лекций по информатике , том 893/1995, стр. 162-176, Springer, ISBN 978-3-540-58907-5