Файл: Учебное пособие издано при поддержке образовательной программы Формирование.docx

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

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

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

Протокол двухфазного подтверждения(2PC) строится из двух фаз, каждая из которых включает в себя два шага. Первая фаза называется фазой голосования и состоит из шагов 1 и 2, вторая фаза (фаза решения) состоит из шагов 3 и 4 (Рис. 2.10):

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

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

Если участник, проголосовавший за подтверждение, получает подтверждение от координатора, он подтверждает транзакцию (выполняет свои внутренние действия по ее завершению). В случае же получения указания отмены выполнение транзакции прекращается.

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

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

Транзакционные мониторы

Для реализации транзакций применяются специальные программные системы – транзакционные мониторы, лежащие в основе множества многоярусных систем. Транзакционные мониторы появились раньше систем типа "клиент/сервер" и трехъярусных архитектур. Наиболее известным монитором транзакций является система CICS, разработанная фирмой IBM в конце 60-х годов и используемая до сих пор.

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

1 ... 4 5 6 7 8 9 10 11 ... 36

Транзакционный удаленный вызов процедуры

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

Рис.2.11.Выполнениеудаленноговызовавнутритранзакционныхскобок

(Т–транзакция,BOT,EOT–открывающаяизакрывающаятранзакционныескобки).

Семантика транзакционного удаленного вызова процедуры (TRPC) такова, что если группа вызовов процедур внутри транзакции успешно завершается, программист имеет гарантии, что всеони завершились. Если вместо этого возникло прерывание выполнения группы вызовов (из-за

каких-либо ошибок), ни один из вызовов не выполняется (совокупный эффект будет таким, как если быни один из вызовов не выполнялся).

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

Функциональность транзакционных мониторов

Современные транзакционные мониторы – очень сложные системы, обычно их функциональность включает в себя:

функциональность и механизмы, необходимые для поддержки удаленных вызовов (язык IDL, серверы имен и каталогов, безопасность и аутентификация, компиляторы переходников).
программные абстракции для работы с TRPC: RPC,

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

ведение журнальных записей, управление восстановлением,

блокировкой и т. д.

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

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

Архитектура транзакционных мониторов

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

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

транзакционный монитор

клиентское приложение