Ю. А. Григорьев, Г. И. Ревунков - Банки данных

Для описания взаимодействия клиента и сервера используют интер­ фейс прикладного программирования Tuxedo ATMI. Функции ATMI пере­ числены в табл. 13.6.

Таб л и ц а 13.6. Интерфейс Tuxedo ATMI

280

Tuxedo АТМ1 прост и обозрим — всего 34 функции (Encina предос­ тавляет около 200 функций). Кратко поясним группы вызовов.

Интерфейс приложения включает две функции, обеспечивающие под­ ключение и отключение клиента от Tuxedo.

Интерфейс управления буферами обеспечивает основные операции с типизированными буферами (отметим, что операции с FML-буферами вы­ делены в особую библиотеку и не включены в Tuxedo ATMI).

Одной из особенностей Tuxedo является возможность организации взаимодействия клиента и сервера в одном из режимов: синхронном, асин­ хронном, диалоговом, с хранимыми очередями. Возможны также модифи­ кации режимов. Кроме того, клиент и (или) сервер могут рассылать сооб­ щения клиентам в асинхронном режиме. Большое число режимов позволяет разработчику выбрать оптимальный для конкретной задачи режим и реали­ зовать его с помощью ATMI.

Интерфейс незатребованных (unsolicited) сообщений требует особых комментариев. Дело в том, что в Tuxedo можно предусмотреть рассылку сообщений от клиентов и (или) серверов приложений клиентам. Сообщения передаются в типизированных буферах и называются незатребованными — получатель сообщения реагирует на них асинхронно своим действиям. Можно организовать рассылку сообщений по именам клиентов либо широ­ ковещательную рассылку всем клиентам приложения (вызов tpbroadcast()). Если необходимо послать (от сервера) сообщение конкретному клиенту, следует воспользоваться вызовом tpnotify(). Рассылка сообщений — удоб­ ный прием для уведомления клиентов о всех событиях, происходящих в приложении. Клиент реагирует на получение сообщения автоматически, передавая управление функции обработки сообщений, адрес которой был предварительно указан в программе-клиенте с помощью вызова tpsetunsol(),

281

13. Выбор общесистемных пакетов

либо периодически опрашивая очередь сообщений при помощи вызова tpchkunsol(). Способ реакции на сообщение напрямую зависит от операци­ онной среды, в которой выполняется программа-клиент, и устанавливается значением одного из полей буфера инициализации приложения.

Интерфейс управления транзакциями включает функции, определяю­ щие начало (вызов tpbegin()) и успешное завершение (tpcommit()) транзак­ ции — как локальной, так и распределенной. Функция tpabort() выполняет откат изменений, выполненных в рамках текущей транзакции ХА-совмести- мыми менеджерами ресурсов (например, SQL-серверами).

Интерфейс динамического объявления сервисов позволяет в процессе работы приложения объявлять дополнительные (к указанным в секции * SERVICE конфигурационного файла) сервисы и связывать их с конкрет­ ными функциями (в терминах языка С).

Tuxedo System/Q — это специализированный менеджер ресурсов в со­ ставе Tuxedo System, управляющий хранимыми на диске очередями запро­ сов. Помещение в очереди и выборка из них — прерогатива служебных процессов, которые запрашивают менеджер очередей для выполнения соот­ ветствующих действий.

Как и в других режимах взаимодействия, в запросе клиент адресуется к конкретному сервису. Для каждого из них на диске строится собственная очередь запросов и очередь ответов. Помещением сообщений в первую и извлечением сообщений из второй ведает сервер TMQUEUE. Сервер TMQFORWARD выбирает сообщения из очереди запросов и помещает со­ общения в очередь ответов.

Упрощенно работа с очередями выглядит следующим образом. Клиент посылает запрос конкретному сервису, направляя его сервису TMQUEUE (вызов tpenqueueO). Последний помещает сообщение в очередь запросов к данному сервису. Сервер TMQFORWARD извлекает сообщение из очереди запросов и направляет его сервису (вызов tpcall()). Последний, выполнив предписанные действия и сформировав ответ на запрос также в виде сообщения, посылает его в очередь ответов (с помощью сервера TMQFORWARD). Клиент при помощи вызова tpdequeue() запрашивает сер­ вер TMQUEUE на получение сообщения из очереди ответов, что тот и вы­ полняет.

Управление транзакциями. Tuxedo System полностью удовлетворяет стандарту обработки распределенных транзакций консорциума Х/Ореп (мо­ дель Х/Ореп DTP). Вначале рассмотрим, как происходит взаимодействие Tuxedo System с СУБД. Приложение может обращаться к нескольким СУБД. Взаимодействие может осуществляться в двух режимах.

В первом, простейшем, режиме управление транзакциями берет на се­ бя сама СУБД. Тогда для указания границ транзакции используются SQLоператоры (на языке Oracle Рго*С, Informix-ESQL/C и др.) конкретной СУБД (COMMIT, ROLLBACK и др.). Tuxedo System не принимает никакого

282

13.2. Варианты выбора распределенной СУБД

участия в обработке такой транзакции. В этом режиме можно задать рас­ пределенную транзакцию, но только в однородной среде (на узлах, затраги­ ваемых транзакцией, обработку данных выполняет одна и та же СУБД, на­ пример Oracle).

Во-втором режиме управление транзакциями берет на себя Tuxedo System. Любая СУБД, с которой взаимодействует ПП, рассматривается как RM. В этом случае необходимо, чтобы СУБД удовлетворяла стандарту Х/Ореп ХА. Сейчас этому стандарту соответствуют Informix-OnLine Dy­ namic Server, Sybase, CA-Openlngres, Oracle, Microsoft SQL Server.

Для управления транзакциями в Tuxedo System используются вызовы tpbeginQ, tpcommitO, tpabort(). Начало транзакции отмечается вызовом tpbegin(). Получив его, System/T (ядро Tuxedo System) добавляет в таблицы транзакций информацию о данной транзакции и связывает с ней все даль­ нейшие действия (действия после tpbegin()), инициируемые прикладной программой, т.е. любые операции над БД, предпринятые после вызова tpbegin(), осуществляются в рамках данной транзакции (одной из многих, одно­ временно контролируемых System/T). Транзакцию можно завершить двумя способами.

Использование tpcommit() вызывает фиксацию всех изменений, дос­ тигнутых в рамках текущей транзакции, т.е. изменений в БД, полученных в результате выполнения операторов SQL, которые следовали после tpbegin(). Функция tpcommitO обращается к System/T, которая вызывает ХА-функ- цию, ответственную за фиксацию транзакции. Таким образом, System/T заставляет СУБД зафиксировать транзакцию, после чего удаляет информа­ цию о данной транзакции из своих внутренних таблиц.

Вызов tpabortO приводит к откату всех изменений, сделанных в рам­ ках текущей транзакции.

На самом деле функция tpcommit() устроена несколько сложнее. Вы­ зов tpcommitO инициирует протокол двухфазной фиксации текущей тран­ закции. Первая фаза — все СУБД (RM) опрашиваются о готовности зафик­ сировать транзакцию (изменения в БД уже внесены, но еще не зафиксиро­ ваны). Вторая фаза — получив от всех RM отклик о готовности, System/T инициирует фиксацию, направляя всем им соответствующую команду через ХА-интерфейс. Если в момент выполнения первой фазы какой-либо из RM не откликнулся, System/T повторяет опрос и, в случае неудачи, направляет всем СУБД RM-команду на откат изменений.

System/T ведет собственный журнал транзакций, куда отображает всю информацию о транзакциях, находящуюся в ее собственных транзакционных таблицах, размещаемых на Доске объявлений. После любого серьезно­ го сбоя, разрушившего внутренние структуры System/T, при перезагрузке системы вся информация о транзакциях восстанавливается на Доске объяв­ лений из журнала транзакций, и, используя ее, System/T откатывает все не­ завершенные транзакции.

283

13. Выбор общесистемных пакетов

Общая схема управления распределенными транзакциями выглядит следующим образом. Разработчик приложения указывает в конфигурацион­ ном файле в секции *GROUPS RM, которые будут принимать участие в транзакции. Для этого используется параметр OPENINFO. В строке OPENINFO указывается информация, необходимая для инициации RM: тип менеджера ресурсов, расположение и имя БД, режим работы с БД (только чтение или чтение и запись). Связь между System/T и RM обеспечивает так называемый сервер управления транзакциями (Transaction Management Server — TMS). Имя TMS указывается параметром TMSNAME секции *GROUPS, а само имя должно совпадать с именем файла, который порожда­ ется утилитой buildtms(). В момент загрузки приложения запускается также процесс TMS, инициирующий подключение приложения к RM, для которого этот TMS был построен. Для каждого RM запускается свой TMS, который и управляет транзакциями, направляемыми к данному менеджеру ресурсов.

Обычно транзакция определяется в клиенте-приложении и содержит вызовы нескольких сервисов, обращающихся к БД. Схема определения рас­ пределенной транзакции представлена ниже:

/* организация распределенной транзакции */

tpbeginO;

if (tpcall(«SRVl»,...)==-l) { tpabortO;

вызвать программу обработки ошибок; завершить выполнение программы;

}

if (tpcall(«SRV2»,...)==.l) {

/* откат всех изменений, достигнутых на данный момент */ tpabortO;

вызвать программу обработки ошибок; завершить выполнение программы;

}

/* здесь фиксируются все изменения в базах данных, выполненные сервисами SRV1 и SRV2 */

tpcommitO;

В этой схеме сервис SRV1 содержит Informix-ESQL/C-операторы и обращается к Informix-OnLine Dynamic Server, в то время как операции с данными сервиса SRV2 определены, например, операторами Oracle Рго*С и манипулируют с БД Oracle.

Баланс загрузки. Для достижения требуемой производительности (ба­ ланс загрузки) в системе Tuxedo предусмотрена динамическая настройка

284

13.2. Варианты выбора распределенной СУБД

Рис. 13.6. Баланс уровня загрузки

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

Рассмотрим пример (рис. 13.6), иллюстрирующий механизм баланса загрузки.

Пример. Пусть сервер приложения составляют два идентичных процесса SRV1(A, В, С), SRV2(A, В, С). В скобках указаны сервисы, предоставляемые каждым процессом. Каждый сервис имеет показатель зафузки, отражающий объем вьиислительных ресурсов, необходимых для его выполнения (для А — 50, для В — 60, для С — 70). Каждый процесс в составе сервера приложений также имеет показатель загруз­ ки: каждый раз, когда запрос передается на обработку данному процессу, показатель зафузки процесса увеличивается на показатель зафузки сервиса, которому этот запрос направлен.

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

Процесс SRV2 запущен с целью разфузки процесса SRV1. Для увеличения про­ пускной способности сервера приложений и максимальной разфузки очереди запросов к нему может быть запущено несколько копий процесса SRV1. Число одновременно за­ пущенных копий процесса указывается в конфигурационном файле приложения и может быть увеличено или уменьшено администратором системы без ее остановки.

285

12, Выбор общесистемных пакетов

Начальные значения показателей загрузки сервисов устанавливаются в кон­ фигурационном файле в секции *SERVICES параметром LOAD. Для нашего приме­ ра эта секция может выглядеть так:

•SERVICES DEFAULT: PRIO=30 А LOAD=50

ВLOAD=60

СLOAD=70

Здесь по умолчанию для всех сервисов установлен приоритет, равный 30 (PRIO=30).

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

Маршрутизация запросов. В системах с распределенными БД встает задача автоматической маршрутизации запроса к БД, содержащей необхо­ димую порцию информации. Tuxedo System поддерживает эффективный механизм, называемый data routing (буквально переводится «маршрутизация данных», но, по сути, это именно маршрутизация запросов).

Предположим, что имеется распределенная банковская система, хра­ нящая и обрабатывающая, помимо прочего, некоторые счета клиентов. Ин­ формация о счетах хранится в БД, распределенной по нескольким городам, где живут клиенты. При этом информация о счетах с номерами 1—10000 хранится в базе данных в Москве, с номерами 10001—20000 — в С.-Пе­ тербурге, с номерами 20001—30000 — в И. Новгороде. В этих городах на­ ходятся подразделения банка, идентифицируемые номерами (С.-Петер­ бург — 2, Москва — 3, Н. Новгород — 5).

Допустим, что необходимо получать информацию о состоянии счета клиента, для чего реализована некоторая программа-клиент, выдающая за­ прос tpcallO — вызов сервиса ACCOUNT, который и поставляет необходи­ мую информацию (рис. 13.7).

Данные передаются и возвращаются в FML-буфер, одним из полей которого является поле ACCOUNTED целого типа (номер счета). Сервис ACCOUNT предоставляется несколькими серверами (процессами), каждый из которых выполняется на компьютере, расположенном в одном из городов (сервер ACCNT в группах BANK1, BANK2, BANK3). Получив запрос tpcall(«ACCOUNT», &buf, ...), система System/T, пользуясь информацией о маршрутизации запроса, расположенной на Доске объявлений, и исходя из значения поля ACCOUNTID FML-буфера направляет запрос на соответст­ вующий компьютер, к базе данных, в которой хранится информация о счете с искомым номером.

286

Рис. 13.7. Маршрутизация запросов в распределенной системе

Запрос может быть направлен и другим сервисам (например, OPEN и др.), предоставляемым сервером ACCNT. Маршрутизация этих запросов выполняется уже по значению поля BRANCHID FML-буфера. Например, в запросе tpcaIl(«OPEN», &buf, ...) на рис. 13.7 FML-буфер buf содержит поле BRANCHID (номер филиала банка) в соответствии со значением которого System/T направляет запрос к тому или иному филиалу.

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

# Описание ресурсов •RESOURCES IPCKEY 62345 MASTER SITE1 MAXACCESSERS 5 MAXSERVERS 5

287

13. Выбор общесистемных пакетов

MAXSERVICES 10

MODEL MP

LDBAL Y

#Компьютеры, на которых выполняются группы серверов (процессов) •MACHINES

DEFAULT: APPDIR...

TUXCONFIG ...

ROOTDIR...

cbmpl LMID=SITE1 comp2 LMID=SITE2 сотрЗ LMID=SITE3

#Группы серверов (процессов) и связанные с ними менеджеры ресурсов:

#группы BANK1, BANK3 — Oracle, группа BANK2 — Informix •GROUPS

BANKl LMID=SITE1 GRPNO=I TMSNAME=TMSORA OPENINFO=«...» BANK2 LMII>SITE2 GRPN0=2 TMSNAME=TMSINF OPENINFO=«...» BANKS LMro=SITE3 GRPN0=3 TMSNAME=TMSORA OPENINFO=«...»

#Описание серверов (процессов)

•SERVERS

ACCNT SRVGRP=BANK1 SRVID=1

ACCNT SRVGRP=BANK2 SRVID=2

ACCNT SRVGRP=BANK3 SRV1D=3

# Описание сервисов, выставляемых на Доску объявлений •SERVICES

DEFAULT: LOAD=50

ACCOUNT PRIO=60 ROUTING=ACCOUNTJD OPEN PRIO=50 ROUTING=BRANCH_ID CLOSE PRIO=40 ROUTING=BRANCH_ID INQUIRY PRIO=50 ROUTrNG=ACCOUNT_ID WITHDRAW PRIO=60 ROUTING=ACCOUNT_ID DEPOSIT PRIO=50 ROUTING=ACCOUNT_ID

# Описание параметров маршрутизации запроса •ROUTING

ACCOUNTJD FIELD=ACCOUNTJD BUFTYPE=«FML»

RANGES=«1-10000:BANK1,10001-20000:BANK2,20001-30000:BANK3^:^» BRANCHJD FIELD=BRANCH_ID

BUFTYPE=«FML»

RANGES=«3:BANK1,2:BANK2,5:BANK3^:^»

В секции •MACHINES описаны компьютеры на которых выполняют­ ся серверы приложения (compl, comp2, сотрЗ). В секции •GROUPS пред­ ставлены группы процессов (серверов). Каждая группа выполняется на от-

288

13.2. Варианты выбора распределенной СУБД

дельном компьютере, на котором работает СУБД (для групп BANK1, BANK3 — это Oracle, для BANK2 — Informix) и хранится БД с информаци­ ей о счетах клиентов. В секции * SERVERS описан сервер (процесс) ACCNT, содержащий сервисы. Этот сервер (модуль) дублируется на трех компьютерах. Секция * SERVICES хранит описание сервиса ACCOUNT со следующими параметрами: показатель загрузки (LOAD=50 — для всех сер­ висов), приоритет сервиса (PRIO=60) и параметр маршрутизации — имя строки в секции *ROUTING (ACCOUNTID). Сами же параметры маршру­ тизации описываются в секции *ROUTING, где для каждого параметра ука­ зывается тип буфера (как правило — FML, хотя может быть и VIEW) и поле буфера запроса, по значению которого проводится маршрутизация, а также диапазон значений поля и группа серверов, к которой будет направлен за­ прос (ключевое слово RANGES).

Преимущество такого подхода к маршрутизации запросов заключает­ ся в том, что конфигурирование системы происходит без переписывания исходных кодов и достигается чисто административными действиями: вне­ сением изменений в конфигурационный файл. Более того, при разработке приложения программист вообще не знает, будет ли БД и приложение рас­ пределенными или централизованными. Ниже представлены спецификации функции (сервиса) ACCOUNT, которая обращается к менеджеру ресурсов СУБД Oracle. Программа написана на Oracle Рго*С.

/* установить указатель на сообщение и получить номер счета*/ transv=(struct aud *) transb->data;

s= transv->H0Mep_C4eTa; /* номер счета*/ /* описать запрос SELECT */

289