Транзакции в распределенных БД

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

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

В современных СУБД предусмотрен так называемый прото­кол двухфазовой (или двухфазной) фиксации транзакций (two-phase commit).

Фаза 1 начинается, когда при обработке транзакции встре­тился оператор commit. Сервер распределенной БД (или компо­нент СУБД, отвечающий за обработку распределенных транзак­ций) направляет уведомление «подготовиться к фиксации» всем серверам локальных БД, выполняющим распределенную тран­закцию. Если все серверы приготовились к фиксации (т. е. от­кликнулись на уведомление и отклик был получен), сервер рас­пределенной БД принимает решение о фиксации. Серверы ло­кальных БД остаются в состоянии готовности и ожидают от него команды «зафиксировать». Если хотя бы один из серверов не откликнулся на уведомление в силу каких-либо причин, будь то аппаратная или программная ошибка, то сервер распределен­ной БД откатывает локальные транзакции на всех узлах, вклю­чая даже те, которые подготовились к фиксации и оповестили его об этом.

Фаза 2 — сервер распределенной БД направляет команду зафиксировать» всем узлам, затронутым транзакцией, и гаран­тирует, что транзакции на них будут зафиксированы. Если связь с локальной базой данных потеряна в интервал времени между Моментом, когда сервер распределенной БД принимает решение о Фиксации транзакции, и моментом, когда сервер локальной А подчиняется его команде, то сервер распределенной БД продолжает попытки завершить транзакцию, пока связь не будет восстановлена.

Мониторы обработки транзакций. Мониторы обработки транзакций (Transaction Processing Monitor — ТРМ), или мониторы транзакций — это программные системы (которые относят к категории middleware, т. е. к посредническому промежуточному ПО), решающие задачу эффективного управления информационно-вычислительными ресурсами в распределенной системе.

Первоначально основной задачей ТРМ в среде клиент — сер­вер было сокращение числа соединений клиентских систем с ба­зами данных. При непосредственном обращении клиента к сер­веру базы данных для каждого клиента устанавливается соедине­ние с СУБД, которое порождает запуск отдельного процесса в рамках операционной системы. ТР-мониторы брали на себя роль концентратора таких соединений, становясь посредником между клиентом и сервером базы данных. Основное назначение ТР-мониторов — автоматизированная поддержка приложений, представленных в виде последовательности транзакций.

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

Важнейшая характеристика ТРМ — поддержка многомашин­ных конфигураций с возможностью миграции серверов прило­жений и их групп на резервный компьютер в случае сбоев в ра­боте основного — является фундаментом, на котором может быть построена система, по надежности близкая к абсолютной. Действительно, применение так называемых безотказных (fault tolerant) компьютеров гарантирует сохранение работоспособно­сти лишь при случайных сбоях, но бессильно перед злоумыш­ленником или в случае механического повреждения.

На современном рынке мониторов транзакций основными являются такие системы, как ACMS (DEC), CICS (IBM), TOP END (NCR), PATHWAY (Tandem), ENCINA (Transarc), TUXEDO Sytem (Novell). Наиболее известной из этой группы является система CICS (Customer Information Control System), работавшая на мэйнфрейме IBM.

Модель обработки транзакций. Понятия транзакции в ТРМ в традиционных СУБД значительно отличаются. Суть остается одной, но в понимании СУБД транзакция — это атомарное дей­ствие над базой данных, в то время как в ТРМ транзакция трактуется гораздо шире. Она включает не только операции с данными, но и любые другие действия — передачу сообщений, выдачу отчетов, запись в индексированные файлы, опрос датчиков и т.д. Это позволяет реализовать в ТРМ прикладные транзак­ции, бизнес-транзакции, которые в СУБД не предусмотрены.

ТРМ опирается на модель обработки распределенных тран­закций X/Open DTP, которая описывает взаимодействие трех субъектов обработки транзакций — прикладной программы (в качестве прикладной программы фигурирует как сервер прило­жения, так и клиент приложения), менеджера транзакций (Transaction Manager — ТМ) и менеджера ресурсов (Resource Manager — RM). Модель представлена на рис. 7.11.

Ha RM возложено управление информационными ресурса­ми — будь то файлы, базы данных или что-то другое. Прило­жение взаимодействует с RM либо с помощью набора специ­альных функций, либо (если в качестве RM выступает реляци­онная SQL-ориентированная СУБД) посредством операторов языка SQL, инициируя необходимые операции с данными. По­следние оформляются как транзакции, обработку которых берет на себя ТМ. Если с помощью монитора транзакций необ­ходимо решать задачи обработки распределенных транзакций, то роль менеджера ресурсов должна играть СУБД, поддержи­вающая двухфазовый протокол фиксации транзакций и удовле­творяющая стандарту X/Open XA (например, Oracle 7.x, ОрenINGRES, Informix-Online 7.x).

Роль ТМ в модели X/Open DTP — это роль диспетчера, глав­ного координатора транзакций. Он обладает полным набором Функций управления как локальными, так и глобальными распределенными транзакциями. В последнем случае транзакция может обновлять данные на нескольких узлах, причем управление данными на них, вообще говоря, осуществляется различными RM. Обработка распределенных транзакций обеспечивается за счет использования протокола двухфазовой фиксации транзакций, который гарантирует целостность данных в информационной системе, распределенной по нескольким узлам, независимо от того, какой RM управляет обработкой данных на каждом таком узле. Эта уникальная возможность как раз и позволяет рассматривать ТРМ как средство интеграции в гетерогенной ин­формационной среде.

Функции ТМ в модели X/Open DTP не ограничиваются только управлением транзакциями. Он берет на себя также ко­ординацию взаимодействия клиента и сервера (поэтому иногда его называют менеджером транзакций и коммуникаций). При этом используется высокоуровневый интерфейс ATMI, пред­ставляющий собой набор вызовов функций на языке третьего поколения (например, на языке Си). С его помощью разработ­чик реализует один из нескольких режимов взаимодействия кли­ента и сервера в рамках расширенной модели «клиент—сервер». Ни сервер приложения, ни клиент приложения не содержат яв­ных вызовов менеджера транзакций — они включены в библио­течные функции ATMI и «невидимы» извне. Таким образом, де­тали взаимодействия прикладной программы и монитора тран­закций скрыты от разработчика, что и дает основание говорить об ATMI как о высокоуровневом интерфейсе.

Функциональный подход. Фундаментальная характеристика ТРМ — функциональный (function-centric) подход к проектиро­ванию бизнес-приложений — сосредоточение всех прикладных функций в серверах приложений по сути означает поставку (или предоставление) функций (functions shipping) для программы-клиента, в отличие от традиционной архитектуры с сервером базы данных, следующей парадигме поставка (или предоставление) данных (data shipping).

Возможность декомпозиции приложений по нескольким уровням с четко очерченными функциями и стандартными ин­терфейсами позволяет создавать легко модифицируемые системы со стройной и целостной архитектурой. Концентрация чисто прикладных функций в серверах приложений и использование унифицированных интерфейсов с другими логическими компо­нентами делает прикладную систему практически полностью не­зависимой как от конкретной реализации интерфейса с пользователем, так и от необходимого ей менеджера ресурсов. Первое означает, что для реализации интерфейса с пользователем может быть выбран практически любой удобный и привычный для разработчика инструментарий, будь то Microsoft Visual C++ или Visual Basic; следствием второго является то, что менеджер ре-сов (например, СУБД) может быть заменен на другой, под­держивающий тот же стандарт интерфейса с прикладной про­граммой. Для реляционных СУБД в качестве унифицированного интерфейса используется встроенный (embedded) SQL. Разуме­ется, в реализации ESQL для каждой конкретной СУБД имеются различия, порой весьма существенные. Поэтому приложение должно быть либо разработано специально с целью работы с конкретной СУБД, либо оно должно быть спроектировано так, чтобы максимально безболезненно перенастраиваться на работу с другой СУБД.

Функциональный подход имеет своим следствием и преиму­щества администрирования приложения. Отныне оно рассмат­ривается как единое целое; сервер приложения имеет набор па­раметров, устанавливаемых его администратором; как и сервер БД, сервер приложения запускается и останавливается специ­альными командами; существуют команды, позволяющие опро­сить параметры сервера приложения и вывести их на консоль.

Таким образом снимается одно из серьезных ограничений производительности и масштабируемости клиент-серверной сре­ды — необходимость поддержки отдельного соединения с базой данных для каждого клиента.