Лекция: Двухфазное подтверждения

Поскольку одновременного выполнения действий на отдаленных компьютерах в соответствии с парадоксом генералов добиться невозможно, для распределенной координации действий используют методы, в которых допустимое выполнение действий в разное время. Рассмотрим один из них — двухфазное подтверждение (two-phase commit, 2PC) .

В этом случае две стороны выполняют действия, оформленные в виде транзакций -атомарних операций, которые выполняются полностью (подтверждаются, commit) или не выполняются совсем (откатываются, rollback).

Примером распределенной транзакции может быть перенесение файла из сервера С1 на сервер С2. Если выполнение этого действия перерывается, при отсутствии атомарности может оказаться, что файл был изъят из сервера С1, но при этом не был перенесен на сервер С2.

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

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

1. Координатор отсылает всем участникам запрос. Он содержит описание действия, которое должно выполняться, например «изъять файл а.txt из корневого каталога». Перед отсылкой информацию о нем сохраняют в журнале транзакций координатора.

2. Участники получают запрос и выполняют транзакцию локально (например, пытаются изъять файл). Информацию о результате этого действия отображают в виде сообщения (Мok — успех, Мabort— неудача), которое хранят в журнале транзакций каждого участника и отсылают координатору. Этот этап завершен, когда координатор получит сообщение от всех участников (или окончится максимальное время ожидания). Отметим, что ни для одной транзакции в конкретный момент еще не было выполнено ни подтверждения, ни отката (например, информацию об исключении файла хранят лишь в памяти).

Вторым этапом является этап принятия решения координатором.

3. Сначала координатор принимает решение относительно подтверждения или отката распределенной транзакции. На этом шаге могут возникнуть две ситуации:

— координатора получает сообщение Мabort хотя бы от одного участника. После этого он создает сообщение MGLOBAL_ROLLBACK хранит его в журнале и отсылает всем участникам;

— координатор получает сообщение Мok от каждого участника. После этого он создает сообщение Mglobal_commit хранит его в журнале и отсылает всем участникам.

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

Рассмотрим выполнение этого протокола при условиях сетевых ошибок. Сначала остановимся на случаях выхода из строя участников протокола.

♦ Если участник выйдет из строя на шаге 2 (во время выполнения транзакции), координатор не получит сообщения о завершении транзакции на протяжении максимального времени ожидания и откатает транзакцию, отослав участникам сообщения MGLOBAL_ROLLBACK -

♦ Если координатор выйдет из строя на шаге 3, после возобновления он должен обратиться к своему журналу транзакций. Когда в нем нет ни одного сообщения MGLOBAL_ХХХ или есть сообщение MGLOBAL_ROLLBACK, то всем участникам отсылают сообщение об откате. Когда в журнале есть MGLOBAL_COMMIT участникам отсылают сообщение о подтверждении.

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

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

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

♦ Когда хотя бы один из участников получил MGLOBAL_XXX необходимо выполнить действие, которое отвечает этому сообщению.

♦ Когда хотя бы один из участников отослал M ABORT транзакцию необходимо откатать.

Если же все участники отослали MОК, но никто из них не получил MGLOBAL_XXX решение не может быть принято, поскольку координатор мог сохранить в журнале (но не успел отослать) MGLOBAL_ROLLBACK через свою внутреннюю ошибку. Такая ситуация и влечет блокировку всех участников. Во время реализации 2РС нужно всегда учитывать возможность такой блокировки.