Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

7.4. Надежная групповая рассылка 431

мы определим разницу между

доставкой

приемом

сообщений. В частности, мы

примем модель, согласно которой распределенная система включает в себя ком-

муникационный уровень. Схема этой модели приведена на рис. 7.10. Сообщения

посылаются и принимаются коммуникационным уровнем распределенной систе-

мы.

Принятое сообщение помещается в локальный буфер коммуникационного

уровня, а затем доставляется приложению, которое логически находится на более

высоком уровне.

Сообщение доставляется приложению

Сообщение принимается

на коммуникационным уровне

Сообщение приходит по сети

Приложение

>|Г"^Комм. уровень

\№

Локальная ОС

Сеть

Рис, 7.10. Логическая организация распределенной системы с разделением

средств получения

доставки сообщения

Основная идея атомарной групповой рассылки состоит в том, что рассылка

членам группы сообщения т однозначно ассоциируется со списком процессов-

получателей. Список рассылки соответствует

представлению

группы

{group

view),

а точнее, представлению составляющих группу набора процессов, с которым ра-

ботает отправитель в момент рассылки сообщения т. Важно заметить, что каж-

дый процесс в этом списке имеет одинаковое представление. Другими словами,

все они согласны с тем, что сообщение т будет доставлено каждому из них,

а больше никому.

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

ладает представлением группы G. Кроме того, допустим, что во время рассылки

некий процесс входит в группу или покидает ее. Это изменение состава группы

объявляется всем процессам, входящим в G. Иначе говоря, происходит измене-

ние представления

{view

change)

путем групповой рассылки сообщения vc о вхо-

де процесса в группу или выходе из нее. Мы имеем два рассылаемых сообщения,

которые находятся в пути одновременно: т и

vc.

Нам необходимо гарантировать,

что т либо будет доставлено всем процессам в

до того, как любой из них полу-

чит сообщение vc, либо вообще не будет доставлено. Отметим, что это требова-

ние

—

что-то вроде полностью упорядоченной групповой рассылки, которую мы

обсуждали в главе 5.

На ум приходит следующий вопрос: если т не получит ни один из процессов,

как мы вообще можем говорить о надежном протоколе групповой рассылки?

принципе имеется только один случай, когда доставка т допускает отказ: ко-

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

этом случае либо все члены

должны получить сообщение об аварийном завер-

432 Глава 7. Отказоустойчивость

шении процесса добавления нового элемента, либо ни один из них. С другой сто-

роны, сообщение т может быть просто проигнорировано всеми членами группы,

что будет соответствовать ситуации поломки отправителя до начала рассылкрг т.

Эта наиболее жесткая форма надежной групповой рассылки гарантирует, что

сообщение, рассылаемое в соответствии с представлением группы G, будет дос-

тавлено каждому нормально функционирующему процессу, входящему в G.

Если отправитель сообщения в ходе рассылки откажет, сообщение будет либо

принято, либо проигнорировано всеми оставшимися процессами. Надежная груп-

повая рассылка с такими свойствами [56, 57] носит название виртуально син-

хронной

{virtually

synchronous).

Рассмотрим четыре процесса, представленные на рис. 7.11, В некоторый мо-

мент времени процесс Pi вступает в группу, которая после этого состоит из про-

цессов Р1, Р2, РЗ и Р4. После рассылки нескольких сообщений процесс РЗ отка-

зывает. До поломки он успевает отправить очередное сообщение процессам Р2 и

Р4, но не Р1. Однако виртуальная синхронность гарантирует, что сообщение во-

обще не будет доставлено, успешно имитируя такое положение, как если бы со-

общение перед поломкой РЗ вообще не отправлялось.

процесс Р1

присоединяется

к группе

Надежная групповая

рассылка

нескольких сообщений

Процесс РЗ снова

присоединяется

Отказ процесса РЗ к группе

Частичная групповая рассылка

от процесса РЗ аннулируется

G = {P1.P2.P3,P4}

Время

—

Рис. 7.11. Принцип виртуально синхронной групповой рассылки

После того как процесс РЗ будет удален из группы, взаимодействие между ос-

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

становлен, его можно будет вновь включить в группу, а затем актуализировать

его состояние.

Принцип виртуальной синхронности вытекает из того факта, что все группо-

вые рассылки происходят в промежутках между изменениями представления.

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

рассылки пройти не в состоянии. В этом смысле этот принцип соответствует ис-

пользованию переменных синхронизации в распределенных хранилищах данных,

которые мы обсуждали в предыдущей главе. Перед тем как изменение представ-

ления вступит в силу, завершаются все групповые рассылки, продолжающиеся

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

мы далее увидим,

—

задача нетривиальная.

7.4. Надежная групповая рассылка 433

Упорядочение сообщений

Виртуальная синхронность позволяет разработчику приложений считать, что

групповые рассылки происходят в различные эпохи, отделенные друг от друга

изменениями в составе группы. Однако мы ничего не говорили о порядке следо-

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

вых рассылок с разным порядком следования:

> неупорядоченные групповые рассылки;

"¥ групповые рассылки в порядке FIFO;

> причинно упорядоченные групповые рассылки;

полностью упорядоченные групповые рассылки.

Надежная неупорядоченная групповая рассылка {reliable unordered multicast) —

это виртуально синхронная групповая рассылка, не дающая никакР1х гарантий

порядка прихода сообщений к различным процессам. Чтобы понять это определе-

ние,

рассмотрим надежную групповую рассылку, реализованную при помощи биб-

лиотеки, в которой имеются примитивы отправки и получения (табл. 7.2). Опе-

рация отправки блокирует вызвавший ее процесс до передачи ему сообщения.

Таблица

7.2.Три

Процесс Р1

Отправка m1

Отправка т2

взаимодействующих в группе процесса

Процесс Р2

Получение m1

Получение т2

Процесс РЗ

Получение т2

Получение m1

Как показано в таблице, пусть процесс Р1 рассылает группе два сообщения,

два других процесса, входящие в группу, ожидают прихода этих сообщений.

Будем считать, что ни один из процессов в ходе этой рассылки не ломается и не

покидает группу. Может случиться, что коммуникационный уровень процесса Р2

сначала примет сообщение тУ, а затем

т2.

Поскольку на порядок доставки сооб-

щений не наложено никаких ограничений, сообщения могут быть доставлены Р2

в порядке их приема. С другой стороны, коммуникационный уровень РЗ может

сначала принять сообщение т2, а затем m1

доставить их РЗ в том же порядке.

В случае

надежной групповой

рассылки в порядке

FIFO {reliable FIFO-ordered

multicast) коммуникационный уровень обязан доставлять входящие сообщения

каждому из процессов в том же порядке, в котором они были отправлены. Рас-

смотрим взаимодействие в группе из четырех процессов, которую иллюстрирует

табл. 7.3. При упорядоченности FIFO имеет значение только то, что m1 всегда

доставляется перед т2, а тЗ, соответственно, перед т4. Это правило соблюдает-

ся всеми процессами группы. Другими словами, если коммуникационный уро-

вень Р2 примет сначала сообщение т2, он будет ожидать получения m1, чтобы

принять и доставить его первым.

Однако какие-либо ограничения на доставку сообщений, посланных разными

отправителями, отсутствуют. Другими словами, если процесс Р2 принимает m1

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

то же время процесс РЗ может принять тЗ перед приемом m1. Упорядочен-

ность FIFO предполагает, что тЗ может быть доставлено РЗ раньше, чем m1, не-

смотря на то, что этот порядок доставки отличается от порядка доставки для Р2.

434 Глава 7. Отказоустойчивость

Таблица 7.3. Четыре процесса в группе с двумя разными отправителями,

и возможный порядок доставки сообщений при надежной рассылке в порядке FIFO

Процесс Р1 Процесс Р2 Процесс РЗ Процесс Р4

Отправка m1 Получение m1 Получение тЗ Отправка тЗ

Отправка т2 Получение т2 Получение

Отправка m4

Получение тЗ Получение т2

Получение т4 Получение т4

И, наконец, при

надежной

причинно

упорядоченной групповой

рассылке {reli-

able

causally-ordered

multicast) сообщения доставляются в порядке потенциаль-

ной причинной связи между ними. Другими словами, если сообщение m1 при-

чинно предшествует сообщению т2, независимо от того, посылались они одним

отправителем или разными, коммуникационный уровень каждого из получате-

лей всегда будет доставлять т2 после того, как примет и доставит m1. Отметим,

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

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

Кроме этих трех вариантов упорядочения можно ввести дополнительные ог-

раничения, определяющие полную упорядоченность сообщений. Полностью

упорядоченная групповая рассылка

{total-ordered multicast)

означает, что незави-

симо от того, как именно упорядочена доставка сообщений (причинно, по FIFO

или не упорядочена вовсе), дополнительно требуется, чтобы сообщения достав-

лялись всем членам группы в одинаковом порядке.

Так, например, в комбинации упорядоченной по FIFO и полностью упорядо-

ченной рассылки процессы Р2 и РЗ (см. табл. 7.3) могут оба получить сначала со-

общение

тЗ,

а затем

—

сообщение

m1.

Однако если Р2 получает сначала тУ, а по-

том

тЗ,

аРЗ

—

сначала

тЗ,

а потом тУ, то ограничения полной упорядоченности

будут нарушены, хотя упорядоченность FIFO будет по-прежнему соблюдена.

Другими словами, сообщение т2 должно быть доставлено после m1,

з.

т4, соот-

ветственно,

—

после тЗ.

Виртуально синхронная надежная групповая рассылка, поддерживающая пол-

ностью упорядоченную доставку, носит название

атомарной групповой рассылки

{atomic

multicasting).

Вместе с рассмотренными ранее тремя различными вариан-

тами упорядоченности сообщений это дает нам шесть видов надежной групповой

рассылки, которые перечислены в табл. 7.4

[191].

Таблица 7.4. Шесть видов виртуально синхронной надежной групповой рассылки

Групповая рассылка Базовая упорядоченность Полная упорядоченность

сообщений доставки

Надежная групповая рассылка

Групповая рассылка в порядке

FIFO

Причинно упорядоченная

групповая рассылка

Атомарная групповая рассылка

Отсутствует

Доставка в порядке FIFO

Причинно упорядоченная

доставка

Отсутствует

Нет

Да

7.4. Надежная групповая рассылка 435

Групповая

рассылка Базовая упорядоченность Полная упорядоченность

сообщений

доставки

Атомарная

рассылка в порядке

FIFO

Атомарная

причинно

упорядоченная

рассылка

Доставка

в порядке FIFO

Причинно

упорядоченная

доставка

Да

Реализация виртуальной синхронности

Обсудим теперь реализацию виртуально синхронной надежной групповой рас-

сылки. Пример такой реализации имеется в Isis, отказоустойчивой распределен-

ной системе, которая несколько лет использовалась на практике. Давайте рас-

смотрим некоторые вопросы реализации, описанные также в [58].

Надежная групповая рассылка в Isis основана на использовании имеющихся

в базовой сети, в частности в сети TCP, механизмов надежной сквозной связи.

Рассылка сообщения т группе процессов реализована путем надежной отправки

сообщения т каждому члену группы. Таким образом, хотя любая передача га-

рантированно успешна, нет никаких гарантий, что сообщение т будет получено

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

го,

как он передаст всем членам группы сообщение т.

Кроме надежной сквозной коммуникации в Isis предполагается, что сообще-

ния из одного источника получаются коммуникационным уровнем в том же по-

рядке, в котором источник их отправляет. На практике это требование разреша-

ется путем использования для сквозной коммуникации соединений TCP.

Основная проблема

—

гарантировать, что все сообщения, посланные пред-

ставлению G, будут доставлены всем правильно работающим процессам из G до

очередного изменения состава группы. Для этого в первую очередь требуется,

чтобы каждый процесс из представления С получил все отправленные туда со-

общения. Отметим, что поскольку отправитель сообщения т в представление G

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

никогда не получат

т.

Поскольку отправитель отказал, эти процессы должны по-

лучить т откуда-то еще. Далее мы рассмотрим, как процесс обнаруживает поте-

рю сообщения.

Решение этой проблемы состоит в том, чтобы каждый процесс в G сохранял

т до тех пор, пока он не будет точно знать, что это сообщение получено BCCMPI

членами G. Если сообщение т получено всеми членами представления G, т на-

зывают

устойчивым

{stable) сообщением. Доставлять разрешается только устой-

чивые сообщения. Чтобы гарантировать устойчивость, достаточно выбрать в G

случайный рабочий процесс и потребовать от него отправки сообщения т всем

остальным процессам.

Для большей конкретности предположим, что текущее представление

—

но имеется необходимость установить новое представление, С,ч1. Без потери

общности можно считать, что G, и

Gi+\

различаются максимум одним процессом.

Процесс Р узнает об изменении представления, получая соответствующее сооб-

щение. Это сообщение может прийти от процесса, желающего войти в группу

или покинуть ее, или от процесса, обнаружившего отказ одного из процессов.

436 Глава

Отказоустойчивость

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

на рис. 7.12, а.

Неустойчивое^ ГГ^ Согласующее

сообщение (iV Kll сообщение (j

® ®

Рис. 7.12. Процесс 4 извещает, что процесс 7 отказал, рассылая сообщение об изменении

представления (а). Процесс 6 рассылает все свои неустойчивые сообщения, сопровождая

их согласующим сообщением (б). Процесс 6 устанавливает новое представление,

получив согласующее сообщение от кого-либо еще (е)

Когда процесс Р получает сообщение об изменении представления на

С,+1,

он

в первую очередь пересылает в G копии всех неустойчивых сообщений, чтобы

они дошли до каждого процесса, входящего в

после чего помечает их как ус-

тойчивые. Напомним, что в Isis сквозные взаимодействия предполагаются надеж-

ными, так что пересылаемые сообщения никогда не теряются. Таким образом,

при пересылке гарантируется, что все сообщения, отправленные в G и получен-

ные хотя бы одним процессом, будут получены всеми правильно работающими

процессами в G, Отметим, что для пересылки неустойчивых сообщений доста-

точно выбрать одного координатора.

Чтобы обозначить, что процесс Р больше не имеет неустойчивых сообщений

и готов установить представление

Gj+u

как только это смогут сделать другие про-

цессы, он рассылает в представление G/+i

согласующее сообщение

{flush

message),

как показано на рис. 7.12, б. После того как Р примет согласующее сообщение

для представления G/+i от какого-либо другого процесса, он может благополучно

установить новое представление, как показано на рис. 7.12, в.

Если процесс Q будет полагать, что текущее представление

—

G/, то, получив

сообщение ш, посланное в соответствии с G/, он доставит его, принимая во вни-

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

что он уже принимал т, он сочтет это сообщение повтором и пропустит его.

Поскольку процесс Q в конце концов примет сообщение о смене представле-

ния на Gj4i, он также сначала перешлет все свои неустойчивые сообщения, после

чего объявит об окончании этой работы посылкой согласующего сообщения чле-

нам представления

Gi+\.

Отметим, что согласно порядку сообщений, который ус-

тановлен базовым коммуникационным уровнем, согласующее сообщение всегда

принимается после неустойчивого сообщения, присланного тем же процессом.

Главный недостаток описанного протокола состоит в том, что он не в состоя-

нии сделать что-либо со сбоями процессов в момент объявления нового измене-

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

представление Gf+i не будет установлено каждым членом представления

Gi+u

ни

7.5. Распределенное подтверждение 437

один процесс из C/+i не откажет (отказ процесса приведет к возникновению но-

вого представления С,ч2)- Эта проблема решается путем объявления об измене-

нии представлений для любого представления

Gi+k

еще до того, как предыдущие

изменения будут установлены всеми процессами. Детали мы оставляем читате-

лю в качестве самостоятельного упражнения.

7.5- Распределенное подтверждение

Задача атомарной групповой рассылки, которую мы обсуждали в предыдущей

главе,

—

это пример более общей задачи, известной под

usiSBSiuneM

распределенно-

го

подтверждения

(distributed commit). Задача распределенного подтверждения

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

сов,

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

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

дет подтверждение транзакции на одном из caiiTOB, задействованных в транзак-

ции. Другие примеры распределенного подтверждения и способы их разрешения

обсуждаются в

[451].

Распределенное подтверждение часто организуется при помощи координато-

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

также участвуют в работе (они называются участниками), в состоянии ли они

локально осуществить запрашиваемую операцию. Эта схема известна под назва-

нием

протокола однофазного подтверждения

(one-phase

commit

protocol).

Он об-

ладает одним серьезным недостатком. Если один из участников на самом деле не

может осуществить операцию, он не в состоянии сообщить об этом координато-

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

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

ния управления параллельным выполнением.

Для практического применения необходима более сложная схема. Обычно

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

ривается ниже. Основной его недостаток состоит в том, что он не в состоянии

эффективно справляться с ошибками координатора. Поэтому был разработан

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

7.5.1.

Двухфазное подтверждение

Первоначально протокол двухфазного

подтверждения

(Two-phase Commit Pro-

tocol

2PC) был описан в

[178].

Рассмотрим распределенную транзакцию, предпо-

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

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

следующих двух фаз, каждая из которых включает в себя два шага [47].

Координатор рассылает всем участникам сообщение

VOTE_REQUEST.

После того как участник получит сообщение

VOTE_REQUEST,

он возвращает

координатору либо сообщение VOTECOMMIT, указывая, что он готов ло-

438 Глава

Отказоустойчивость

кально подтвердить свою часть транзакции, либо сообщение VOTEABORT

в противном случае.

Координатор собирает ответы участников. Если все участники проголосовали

за подтверждение транзакции, координатор начинает осуществлять соответ-

ствующие действия

посылает всем участникам сообщение GLOBAL_

COMMIT Однако если хотя

бы

один участник проголосовал

за

прерывание

транзакции, координатор принимает соответствующее решение

рассылает

сообщение GLOBAL_ABORT

Каждый

из

участников, проголосовавших

за

подтверждение, ожидает итого-

вого решения координатора. Если участник получает сообщение GLOBAL_

COMMIT,

он

локально подтверждает транзакцию.

случае

же

получения со-

общения СЮБЛ1_Л50/?Г транзакция локально прерывается.

Первая фаза (фаза голосования) состоит

из

шагов

1 и 2,

вторая (фаза реше-

ния)

—

из

шагов

3 и

4. Эти четыре шага показаны на диаграмме конечного авто-

мата (рис. 7.13).

Commit

[ INIT

)

Vote-request

Vote-abort

( WAIT

Vote-commit

Global-abort

/ X

Global-commit

( ABORT )

(COMMIT)

Vote-request

Vote-a

INIT

( READY

)

Global-commit

Подтверждение

ABORT )

(COMMIT)

Рис. 7.13. Координатор

протоколе 2РС

виде конечного автомата (а). Участник

в виде конечного автомата

(б)

Когда

при

использовании базового протокола

2РС в

системе появляются

ошибки, возникают определенные проблемы.

первую очередь, отметим,

что

как координатор, так

участники имеют такие состояния,

которых они блоки-

руются

ожидают прихода сообщений. Соответственно, если процесс отказыва-

ет, работа протокола легко может быть нарушена, поскольку другие процессы

будут бесконечно ожидать

от

него сообщения.

По

этой причине вводятся меха-

низмы тайм-аута.

Глядя

на

конечные автоматы, представленные

на

рисунке, можно заметить,

что всего существует три состояния,

которых координатор или участник могут,

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

жет, находясь

начальном состоянии

INIT,

ожидать сообщения

VOTEJREQUEST

от координатора. Если

течение некоторого времени этого сообщения нет, уча-

стник приходит

выводу

необходимости локального прерывания транзакции

и посылает координатору сообщение VOTE_ABORT

Точно

так же

координатор, блокированный

состоянии

WAIT,

ожидает при-

хода голосов всех участников. Если

течение некоторого времени

не

будут

7.5. Распределенное подтверждение 439

собраны

все

голоса, координатор решает, что транзакцию необходимо прервать,

и рассылает всем участникам сообщение GLOBAL_ABORT.

И, наконец, участник может быть блокирован

состоянии

READY,

ожидая

глобального объявления результатов голосования, рассылаемого координатором.

Если это сообщение

за

определенный период времени не приходит, участник

не

может просто решить прервать транзакцию. Вместо этого он должен определить,

какое же сообщение на самом деле посылал координатор. Самым простым реше-

нием этого вопроса будет блокировка участника до момента восстановления

ко-

ординатора.

Более правильным решением будет разрешить участнику

контакт с другим

участником,

чтобы

он

мог

по

текущему состоянию Q решить, что

же

ему де-

лать дальше. Так, например, пусть

перешел в состояние

COMMIT.

Это возмож-

но только

в том

случае, если координатор

до

поломки послал

сообщение

GLOBAL_COMMIT.

Видимо, до Р это сообщение не дошло. Соответственно, Р те-

перь может прийти

выводу

необходимости локального подтверждения. Точ-

но

так же

если

находится

состоянии

ABORT,

может уверенно прерывать

свою часть транзакции.

Теперь предположим, что Q пребывает

состоянии

INIT.

Такая ситуация мо-

жет произойти, если координатор разошлет всем участникам сообщения VOTE_

REQUEST

это

сообщение дойдет

до Р

(который ответит

на

него посылкой

со-

общения VOTEjCOMMIT),

но не

дойдет

до Q.

Другими словами, координатор

может отказать

во

время рассылки сообщения

VOTE_REQUEST.

этом случае

правильно будет прервать транзакцию:

Р,

могут осуществР1ть переход

со-

стояние

ABORT,

Наиболее сложную ситуацию

мы

получим, если Q также будет находиться

состоянии

READY,

ожидая ответа

от

координатора. Так, если окажется,

что все

участники находятся

состоянии

READY,

конкретное решение принять невоз-

можно. Проблема состоит

том, что все участники готовы подтвердить транзак-

цию,

но для этого

им

необходим голос координатора. Соответственно, протокол

блокируется до момента восстановления координатора.

Различные варианты иллюстрирует табл.

7.5.

Таблица 7.5. Действия, предпринимаемые участником Р в состоянии READY

и контакте с участником Q

Состояние участника

Действие участника

COMMIT Перейти в состояние COMMIT

ABORT Перейти

состояние ABORT

INIT Перейти

состояние ABORT

READY Связаться

другим участником

Чтобы гарантировать, что процесс действительно восстановился, нужно что-

бы

он

сохранял свое состояние при помощи средств длительного хранения дан-

ных

(как

сохранять защищенным

от

отказов способом,

мы

поговорим позже

этой главе). Так, например, если участник находился

состоянии

INIT,

то

после

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

он

может решить локально прервать транзакцию

сообщить

об

440 Глава 7. Отказоустойчивость

этом координатору. Точно так же если он уже принял решение и в момент по-

ломки находился в состоянии COMMIT или

ABORT,

то при восстановлении он

снова придет в выбранное состояние и повторно сообщит свое решение коорди-

натору.

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

READY.

В этом случае при восстановлении он не может определить на основании собст-

венной информации, что делать дальше, завершать или прерывать транзакцию.

Соответственно, чтобы выяснить, что делать этому процессу, его следует заста-

вить связаться с другими участниками, как это проделывалось в ситуации исте-

чения тайм-аута в состоянии

READY,

описанной ранее.

Координатор имеет только два критических состояния, за которыми надо сле-

дить.

Когда он начинает протокол 2РС, он должен сохранить сведения о том,

что он находится в начальном состоянии

WAIT,

чтобы иметь возможность при

необходимости после восстановления повторно разослать сообщение VOTE_

REQUEST

всем участникам. Кроме того, если в ходе второй фазы он принял ре-

шение, следует сохранить это решение, чтобы после восстановления координато-

ра его также можно было разослать повторно.

Схема действий координатора иллюстрирует листинг

7.1.

Координатор начи-

нает с групповой рассылки всем участникам сообщения VOTE REQUESTлля то-

го,

чтобы собрать их голоса. Он записывает это действие, после чего входит в со-

стояние

WAIT,

в котором ожидает прихода голосов участников.

Листинг

7.1.

Схема действий, предпринимаемых координатором

согласно протоколу двухфазного подтверждения

ДЕЙСТВИЯ КООРДИНАТОРА:

записать START_2PC

локальный журнал;

разослать

\/ОТЕ_

REQUEST всем участникам;

пока собраны не все голоса

{

ожидать прихода голосов;

если время вышло

{

записать GLOBAL_ABORT

локальный журнал;

разослать GLOBAL_ABORT всем участникам;

выход;

}

записать голос;

}

если все участники прислали \/0ТЕ_С0ММ1Т

координатор голосует COMMIT

{

записать GLOBAL_COMMIT

локальный журнал;

разослать GLOBAL_COMMIT всем участникам;

}

противном случае

{

записать GLOBAL_ABORT

локальный журнал;

разослать GLOBAL_ABORT всем участникам;

}

Если собраны не все голоса, а недостающие в течение заданного времени не

присланы, координатор приходит к выводу, что один или более участников на-

ходятся в нерабочем состоянии. Это означает, что он должен прервать транзак-

цию и разослать остальным участникам сообщение GLOBALABORT

Если не произошло никаких отказов, координатор в конечном итоге соберет

все голоса. Если все участники, так же как и координатор, проголосовали за под-