9. Аппаратная независимость

По этому вопросу фактически нечего сказать — заголовок раздела говорит сам за себя. Парк вычислительных машин современных организаций обычно включает множество раз- ных компьютеров — машины IBM, машины ICL, машины HP, персональные компьютеры, различного рода рабочие станции и т.д. Поэтому действительно существует необходимость интегрировать данные всех этих систем и предоставить пользователю "образ единой сис- темы". Следовательно, желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины уча- ствовали в работе распределенной системы как равноправные партнеры.

10. Независимость от операционной системы

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

функционирования под различными операционными системами для многих платформ — включая различные операционные системы на одном и том же оборудовании (например, что- бы версия СУБД для операционной системы MVS, версия для UNIX и версия для Windows NT могли совместно использоваться в одной и той же распределенной системе).

11. Независимость от сети

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

12. Независимость от типа субд

В этом разделе мы рассмотрим, с чем приходится сталкиваться при отказе от требо- вания строгой однородности системы. Необходимость такого сильного ограничения вы- зывает сомнения. Действительно, все, что необходимо, — так это то, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и со- всем необязательно, чтобы это были копии одной и той же версии СУБД. Например, СУБД Ingres и Oracle обе поддерживают официальный стандарт языка SQL, а значит, можно добиться, чтобы узел с СУБД Ingres и узел с СУБД Oracle обменивались сообще- ниями между собой в контексте распределенной системы. Иными словами, распределен- ные системы вполне могут быть, по крайней мере в некоторой степени, неоднородными.

Поддержка неоднородности весьма заманчива. На практике современное программ- ное обеспечение обычно используется не только на многих различных компьютерах и в среде многих различных операционных систем. Оно довольно часто используется и с различными СУБД, и было бы очень хорошо, если бы различные СУБД можно было ка- ким-то образом включить в распределенную систему. Иными словами, идеальная рас- пределенная система должна обеспечивать независимость от СУБД.

Однако эта тема слишком обширна (и важна на практике), поэтому ниже ей посвящен отдельный раздел (см. раздел 20.6).

20.4. Проблемы распределенных систем

В этом разделе подробно рассматриваются проблемы, которые упоминались в разде- ле 20.3. Ключевая проблема распределенных систем состоит в том, что коммуникацион- ные сети, по крайней мере сети с "большой протяженностью" или глобальные сети, пока являются медленными. Обычная глобальная сеть чаще всего имеет среднюю скорость передачи данных от 5 до 10 тысяч байтов в секунду. Обычный же жесткий диск имеет скорость обмена данными около 5-10 миллионов байтов в секунду. (С другой стороны, некоторые локальные сети поддерживают скорость обмена данными того же порядка, что и диски.) Поэтому основная задача распределенных систем — минимизировать ис- пользование сетей, т.е. минимизировать количество и объем передаваемых сообщений. Эта задача, в свою очередь, сталкивается с проблемами в нескольких дополнительных областях. Приведем список таких областей, хотя мы и не гарантируем, что он полный.

• Обработка запросов

• Управление каталогом

• Распространение обновлений

• Управление восстановлением

• Управление параллельностью

Обработка запросов

Чтобы решить задачу минимизации использования сети, процесс оптимизации запро- сов должен быть распределенным, как и процесс выполнения запросов. Иначе говоря, в общем случае процесс оптимизации будет содержать этап глобальной оптимизации, за которым последуют этапы локальной оптимизации на каждом задействованном узле. Например, предположим, что запрос Q представлен на рассмотрение узлу X, и предполо- жим, что запрос Q включает объединение отношения Ry, в котором сто кортежей на узле Y, с отношением Rz, в котором миллион кортежей на узле Z. Оптимизатор на узле X должен выбрать глобальную стратегию выполнения запроса Q. В данном случае очевид- но, что было бы выгоднее переслать отношение Ry на узел Z, а не отношение Rz на узел Y (ну и, конечно же, не оба отношения Ry и Rz на узел X). Затем, после принятия решения о пересылке отношения Ry на узел Z, реальная стратегия выполнения объединения на узле Z будет определяться локальным оптимизатором этого узла.

Приведенная ниже подробная иллюстрация процесса выполнения запроса основана на примере, взятом из [20.13], который, в свою очередь, заимствован из ранней работы Ротни (Rothnie) и Гудмана (Goodman) [20.33].

■ База данных поставщиков и деталей (упрощенная)

S { S#, CITY } 10 ООО хранимых кортежей на узле А

Р {Pi, COLOR } 100 ООО хранимых кортежей на узле В

SP { Si, Pi } 1 000 000 хранимых кортежей на узле А

Предположим, что каждый хранимый кортеж имеет длину 25 байт (200 бит).

■ Запрос ("Получить номера лондонских поставщиков красных деталей")

( ( S JOIN SP JOIN Р ) WHERE CITY = 'London' AND

COLOR = COLOR ('Red') ) { St }

• Расчетные количества некоторых промежуточных результатов Количество красных деталей 10 Количество поставок, выполненных поставщиками из Лондона 100 ООО

• Предполагаемые параметры линий передачи данных Скорость передачи данных 50 ООО бит/с Задержка доступа 0,1 с

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

( общая задержка доступа ) +

( общий объем данных / скорость передачи данных )

В этом случае она сводится к следующей формуле (время в секундах). ( количество сообщений / 10 ) + (количество битов / 50000 )

1. Пересылка записей о деталях на узел А и обработка запроса на узле А.

Т[1] = 0,1 + ( 100000 * 200 ) / 50000 = 400 с (приблизительно 6,67 мин)

2. Пересылка записей о поставщиках и поставках на узел Б и обработка запроса на узле Б.

Т[2) = 0,2 + { ( 10000 + 1000000 ) * 200 ) / 50000 = 4040 с (приблизительно 1,12 ч)

3. Соединение отношений поставщиков и поставок на узле А, выборка из результирую- щего отношения кортежей для поставщиков из Лондона с последующей проверкой на узле Б для каждого выбранного поставщика соответствующих деталей, является ли деталь красной. Каждая из таких проверок включает два сообщения: запрос и ответ. Время передачи этих сообщений будет мало по сравнению с задержкой доступа.

Т[3] = 20000 с (приблизительно 5,56 ч)

4. Выборка красных деталей на узле Б и проверка для каждой из выбранных деталей на узле А наличия поставок, связывающих эту деталь с поставщиком из Лондона. Каждая из таких проверок включает два сообщения. Время передачи этих сообще- ний также будет мало по сравнению с задержкой доступа.

Т[4] = 2 с (приблизительно)

5. Соединение отношений поставщиков и поставок на узле А, выборка из результата кортежей для поставщиков из Лондона, проекция этих кортежей по атрибутам Si и Pi и пересылка результата на узел Б. Завершение обработки на узле Б.

Т[5] = 0,1 4 ( 100000 * 200 ) / 50000 = 400 с (приблизительно 6,67 мин)

6. Выборка красных деталей на узле Б и пересылка результата на узел А. Завершение обработки на узле А.

Т[6] - 0,1 + ( 10 * 200 ) / 50000 = 0,1 с (приблизительно)

На рис. 20.4 подведены итоги результатов обработки различных вариантов запроса.

Стратегия	Метод	Время передачи данных
1	Пересылка Р на А	6,67 мин
2	Пересылка S и SP на Б	1,12 ч
3	Для каждой поставки из Лондона проверка	5,56 ч
	красной детали
4	Для каждой красной детали проверка по-	2,00 с
	ставщика из Лондона
5	Пересылка поставок из Лондона на Б	6,67 мин
6	Пересылка красных деталей на А	0,10 с (самое малое)

Рис. 20.4. Возможные стратегии распределенной обработки запроса (сводка)

Прокомментируем эти результаты.

■ Каждая из шести стратегий представляет возможный подход к проблеме, но от- клонения по времени передачи данных огромны. Наибольшее время в двамшлио- на раз больше, чем наименьшее.

• Скорость обмена данными и задержки доступа — важные факторы в выборе стратегии.

• Для плохих стратегий время вычислений и ввода-вывода ничтожно мало по сравне- нию со временем передачи данных. С другой стороны, для лучших стратегий это со- отношение может зависеть от дополнительных обстоятельств [20.35]. Такого боль- шого расхождения может не быть в случае использования быстрых локальных сетей.

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

Управление каталогом

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

1. Централизованное хранение. Единственный общий каталог хранится на отдельном центральном узле.

1. Полная репликация. Общий каталог целиком хранится на каждом узле.

2. Частичное хранение. Каждый узел поддерживает собственный каталог для объек- тов, которые на нем хранятся. Общий каталог представляет собой объединение всех этих несвязанных локальных каталогов.

3. Сочетание подходов 1 и 3. Каждый узел поддерживает свой локальный каталог, как предусмотрено при подходе 3. Кроме того, отдельный центральный узел со- провождает объединенную копию всех этих локальных каталогов, как предусмот- рено при подходе 1.

Каждый подход имеет свои недостатки. При подходе 1, очевидно, нарушается прин- цип "Отсутствие опоры на центральный узел". При подходе 2 в значительной мере утра- чивается независимость узлов, поскольку всякое обновление каталога должно распро- страняться на каждый узел. При подходе 3 нелокальные операции становятся слишком затратными (для поиска удаленного объекта требуется досгуп в среднем к половине всех узлов). Подход 4 более эффективный по сравнению с подходом 3 (для поиска удаленного объекта требуется доступ лишь к одному удаленному каталогу), но в этом случае вновь нарушается принцип отсутствия центрального узла. Поэтому на практике системы обыч- но не используют ни один из этих подходов! В качестве примера рассмотрим подход, ко- торый применяется в версии R* системы R [20.39].

Прежде чем описать структуру каталога системы R*, необходимо сказать несколько слов о механизме именования объектов в этой системе. Присвоение имен объектам — это вообще очень важный вопрос для распределенных систем. Поскольку два отдельных узла X и Y могут иметь объект (скажем, базовую переменную-отношение) с именем А, требуется некоторый механизм (обычно — уточнение с помощью имени узла) для того, чтобы "устранить неоднозначность", т.е. гарантировать уникальность расширенного сис- темного имени. Однако, если уточненные имена, такие как Х.А и Y.A, будут предостав-

ляться системой и пользователю, будет нарушено требование независимости от разме- щения. Поэтому необходимы средства отображения имен для пользователя в соответст- вующие системные имена.

Теперь изложим подход к рассматриваемой проблеме, принятый в системе R*. В этой системе различаются печатные имена, с помощью которых пользователи обычно обра- щаются к объектам (например, в предложении SELECT языка SQL), и общесистемные име- на, которые представляют собой глобальные уникальные внутренние идентификаторы для этих же объектов. Расширенные системные имена имеют четыре следующих компонента.

• Идентификатор создателя, т.е. идентификатор пользователя, который создал объект.

• Идентификатор узла создателя, т.е. идентификатор узла, на котором была введе- на соответствующая операция CREATE (создать).

• Локальное имя, т.е. не уточненное имя объекта.

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

Идентификаторы пользователя уникальны на узле, тогда как идентификаторы узла уникальны глобально. Рассмотрим, например, следующее расширенное системное имя.

MARILYN g NEWYORK . STATS g LONDON

Оно обозначает объект (возможно, базовую переменную-отношение) с локальным именем STATS, созданный пользователем MARILYN на узле в Нью-Йорке и первоначально сохраненный¹¹ на узле в Лондоне. Это имя гарантировано защищено от каких-либо изменений, даже если объект будет перемещен на другой узел (см. ниже).

Как уже указывалось, пользователи обычно ссылаются на объекты с помощью печат- ных имен. Печатное имя представляет собой простое, не уточненное имя— компонент "локальное имя" из расширенного системного имени (в примере это STATS) или синоним для соответствующего расширенного системного имени, который в системе R* определя- ется с помощью специального оператора CREATE SYNONYM, как, например, показано ниже.

CREATE SYNONYM MSTATS FOR MARILYN § NEWYORK . STATS 8 LONDON ;

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

SELECT FROM STATS ;

SELECT FROM MSTATS ;

В первом случае, т.е. при использовании локального имени, система будет подразу- мевать, что все компоненты расширенного системного имени определяются по умолча- нию, а именно, что объект создан данным пользователем, создан на данном узле и со- хранен на данном узле. Кстати, благодаря такому допущению по умолчанию старые при- ложения системы R могут выполняться без каких-либо исправлений в новой версии сис- темы R* (т.е. после переопределения данных системы R для системы R*; напомним, что система R была предшествующим прототипом системы R*).

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

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

1. Элементы каталога для каждого объекта, местом рождения которого является дан- ный узел.

2. Элементы каталога для каждого объекта, хранимого в данный момент на данном узле.

Предположим теперь, что пользователь выдал запрос, содержащий ссылку на сино- ним MSTATS. Сначала система выполнит поиск соответствующего расширенного систем- ного имени в подходящей таблице синонимов (простой локальный просмотр). После то- го как станет известен узел рождения (в нашем примере это узел в Лондоне), можно бу- дет опросить каталог узла в Лондоне (здесь мы для общности подразумеваем удаленный просмотр — первое удаленное обращение). Каталог узла из Лондона будет содержать элемент для объекта в соответствии с п. 1. Если объект по-прежнему хранится на узле в Лондоне, он будет найден. Однако, если объект перемещен, скажем, на узел в Лос- Анджелесе, элемент каталога на узле в Лондоне будет содержать сведения об этом и сис- тема должна будет опросить каталог на узле в Лос-Анджелесе (второе удаленное обра- щение). Каталог на узле в Лос-Анджелесе будет содержать элемент для искомого объек- та согласно п. 2. Таким образом, для поиска объекта будет выполнено не более двух уда- ленных обращений.

Кроме того, если объект вновь потребуется переместить, скажем, на узел в Сан- Франциско, системой будут выполнены следующие действия.

• Вставка элемента в каталог на узле в Сан-Франциско.

• Удаление элемента каталога на узле в Лос-Анджелесе.

• Обновление элемента каталога на узле в Лондоне, который теперь будет указывать на узел в Сан-Франциско вместо узла в Лос-Анджелесе.

В результате объект всегда может быть найден с помощью не более двух удаленных обращений. И это полностью распределенная схема — нет никакого узла с основным ка- талогом и нет никакого единого источника ошибок внутри системы.

Отметим, что схема идентификации объектов, которая используется в распределен- ной СУБД DB2, хотя и подобна описанной выше, не полностью совпадает с ней.

Распространение обновлений

Основная проблема репликации данных, как указывалось в разделе 20.3, заключается в том, что обновление любого заданного логического объекта должно распространяться на все хранимые копии этого объекта. Сложности, которые немедленно возникают в этом случае, состоят в том, что некоторый узел, содержащий копию данного объекта, в момент обновления может оказаться недоступным, поскольку или он сам, или канал дос- тупа находится в аварийном состоянии. Таким образом, очевидная стратегия немедлен-

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

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

• Одна копия для каждого реплицируемого объекта устанавливается как первичная копия, а все оставшиеся копии — как вторичные.

• Первичные копии различных объектов находятся на различных узлах (поэтому данная схема все же является распределенной).

• Операции обновления считаются логически завершенными, как только обновлена первичная копия. Узел, содержащий такую копию, будет отвечать за распростра- нение обновления на вторичные копии в течение некоторого последующего вре- мени. (Это "последующее время", тем не менее, должно предшествовать операции завершения транзакции COMMIT, если должны гарантироваться ACID-свойства рас- пределенных транзакций, т.е. свойства атомарности, согласованности, изолиро- ванности и долговечности. Дополнительные замечания по этому вопросу будут приведены ниже.)

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

Замечание. Как уже указывалось, вследствие требования гарантии соблюдения АСШ-свойств транзакций, весь процесс распространения обновлений должен быть за- вершен прежде, чем соответствующая транзакция может быть зафиксирована ("синхронная репликация"). Однако несколько коммерческих продуктов поддержива- ют менее строгую форму репликации, в которой распространение обновлений откла- дывается на некоторое более позднее время (возможно, на некоторое указываемое пользователем время) и не обязательно в рамках соответствующей транзакции ("асинхронная репликация"). Фактически термин репликация, к сожалению, в какой-то степени узурпирован этими продуктами, в результате чего, по крайней мере на ком- мерческом рынке, под ним подразумевается, что распространение обновлений откла- дывается до тех пор, пока соответствующая транзакция не завершится (например, [20.1], [20.18] и [20.21]). Проблема подобного подхода с задержкой распространения обновлений заключается, конечно, в том, что база данных не может больше гаранти- ровать согласованности всех ее данных в любой момент. В действительности пользо- ватель даже может не знать, согласованна ли база данных.

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

1. Концепция репликации в системе с задержкой распространения обновлений мо- жет рассматриваться как применение идеи моментальных снимков, речь о кото- рых шла в главе 9¹². На самом деле лучше было бы использовать другой термин для такого вида репликации. Тогда можно было бы сохранить термин "реплика" для обозначения того, что понимается под ним в обычном разговоре (а имен- но — точной копии).

Замечание, Мы не утверждаем, что задержка распространения обновлений — пло- хая идея. Это, очевидно, самое лучшее, что можно было сделать при определенных обстоятельствах, как мы убедимся, например, в главе 21. Суть в том, что задержка распространения подразумевает, что "реплики" — не настоящие реплики, а систе- ма — не настоящая распределенная система баз данных.

2. Одна из причин (может быть, даже главная причина), по которой репликация в коммерческих продуктах реализована с задержкой расширения, заключается в следующем: альтернатива, т.е. обновление всех дубликатов перед выполнением операции COMMIT, требует поддержки двухфазной фиксации транзакции (см. ниже), что может существенно повлиять на производительность системы. Именно по этой причине в компьютерных журналах иногда встречаются статьи с озадачивающими названиями, например "Репликация или двухфазная фикса- ция?" (озадачивающими потому, что, по существу, в их названиях сравниваются качества совершенно разных предметов).

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

Как уже разъяснялось в разделе 20.3, управление восстановлением в распределенных системах обычно базируется на протоколе двухфазной фиксации транзакций (или не- которых его вариантах). Двухфазная фиксация транзакций требуется в любой среде, где отдельная транзакция может взаимодействовать с несколькими автономными менедже- рами ресурсов. Однако в распределенных системах ее использование приобретает ис- ключительную важность, поскольку рассматриваемые менеджеры ресурсов, т.е. локаль- ные СУБД, функционируют на отдельных узлах и поэтому в значительной мере авто- номны. Рассмотрим некоторые особенности этого процесса.

1. Принцип "Отсутствие опоры на центральный узел" предписывает, что функции координатора не должны назначаться одному выделенному узлу в сети, а должны выполняться на различных узлах для различных транзакций. Обычно управление транзакцией передается на тот узел, на котором она была иниции- рована. Поэтому каждый узел должен быть способен выполнять функции коор- динатора для некоторых транзакций и выступать в качестве участника выпол- нения остальных транзакций.

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

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

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

_Г

Принудительный вывод в файл Координатор журнала строки о принятом решении — конец фазы 1 и начало фазы 2

t1 t4 t5 t6 t9

о. с i

f

а

I*

о 5

eg

_L

t2

Участник

t3

В состоянии ожидания

t7

18

Рис. 20.5. Двухфазная фиксация транзакции

Время на этом рисунке идет слева направо (более или менее!). Будем считать для простоты, что для рассматриваемых транзакций выполняется операция COMMIT, а не ROLLBACK. После получения запроса на операцию COMMIT координатор организует сле- дующий двухфазный процесс.

• Каждому участнику координатор отдает распоряжение "приготовиться к фиксации или откату" транзакции. На рис. 20.5 показано сообщение "приготовиться", отосланное в момент tl и полученное участником в момент t2. Далее участник принудительно по- мещает запись в журнал локального агента из своего физического журнала, а затем выдает координатору подтверждение "ОК". Конечно, если возникнет какая-либо ошибка (в частности, если произойдет сбой локального агента), будет отослано сооб- щение "Not ОК". На рисунке это сообщение, которое для простоты обозначено как "ОК", переслано в момент tj и получено координатором в момент t4. Как уже отме- чалось выше, участник теперь теряет независимость: он должен делать то, что ему бу- дет предписывать координатор. Кроме того, любые ресурсы, которые заблокированы локальным агентом, должны оставаться заблокированными до тех пор, пока участ- ник, получивший распоряжение координатора, его не выполнит.

• После получения подтверждения ото всех участников координатор принимает ре- шение либо зафиксировать транзакцию, если все ответы — "ОК", либо выпол- нить откат транзакции в противном случае. Затем в момент t5 координатор до- бавляет в журнал запись о своем решении. Время t5 служит границей между пер- вой и второй фазами фиксации транзакции.

• Будем считать, что было принято решение о фиксации транзакции. В этом случае координатор отдаст распоряжение всем участникам "выполнить", т.е. запустить обработку операции фиксации для локального агента. На рис. 20.5 показано сооб- щение "выполнить", отосланное в момент t6 и полученное участником в момент Ы. Участник выполняет операцию фиксации для локального агента и отсылает подтверждение "выполнено" координатору. На рисунке сообщение отослано ко- ординатору в момент t8 и получено в момент t9.

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

На практике, конечно, этот процесс, в целом, значительно сложнее, чем описано вы- ше, поскольку необходимо еще позаботиться о возможных отказах узла или каналов свя- зи. Предположим, например, что на узле координатора сбой произошел в некоторый мо- мент t между отметками времени t5 и t6. В процессе восстановления работы узла про- цедура повторного пуска обнаружит в журнале сведения о том, что в момент отказа не- которая транзакция была во второй фазе двухфазного процесса фиксации, после чего процесс будет продолжен, начиная с пересылки участникам сообщений "выполнить". Отметим, что в период от t3 до 17 участник находится в состоянии ожидания заверше- ния транзакции. Если координатор попал в аварийную ситуацию, как указывалось выше, в момент t, период ожидания может оказаться достаточно длительным.

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

Но несмотря на этот удручающий факт существует ряд усовершенствований, которые можно внести в основной алгоритм для повышения его производительности.

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

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

• И в-третьих, существуют два важных варианта основной схемы, которые называ- ются вариантами предполагаемой фиксации и предполагаемого отката соответ- ственно [20.15]. Они будут описаны ниже.

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

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

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

Схема предполагаемого отката — это противоположная схема. От участников тре- буется подтверждение сообщений "зафиксировать", а не сообщений "откатить". И коор- динатор может забыть о транзакции после того, как передаст широковещательное сооб- щение о своем решении, если это решение — "откатить". Если участник в период ожи- дания завершения транзакции попадает в аварийную ситуацию, то в процессе рестарта он должен будет опросить координатора о принятом им решении. Если координатор еще помнит о данной транзакции, т.е. еще ожидает подтверждений от ее участников, его ре- шением будет "зафиксировать", в противном случае — "откатить".

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

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

Управление параллельностью

Как объяснялось в разделе 20.3, управление параллельным доступом в большинстве распределенных систем строится на использовании механизма блокирования, т.е. точно так, как и в большинстве не распределенных систем. Однако в распределенных системах запросы на проверку, установку и отмену блокировки становятся сообщениями (если считать, что рассматриваемый объект расположен на удаленном узле), а сообщения оз- начают дополнительные накладные расходы. Рассмотрим, например, транзакцию Т, ко- торой необходимо обновить объект, для которого существуют дубликаты на л удаленных узлах. Если каждый узел отвечает за блокировку объектов, которые на нем хранятся (как предполагается в соответствии с принципом локальной независимости), то непосредст- венная реализация будет требовать по крайней мере 5л сообщений:

л запросов на блокировку;

л разрешений на блокировку;

л сообщений об обновлении;

л подтверждений;

л запросов на снятие блокировки.

Конечно, мы можем разумно воспользоваться, как и в предыдущем случае, "комбинированными" сообщениями. Например, можно объединить сообщение запроса на блокировку и сообщение об обновлении, а также сообщение о разрешении блокиров- ки и сообщение о подтверждении. Но даже в этом случае общее время обновления может быть на порядок больше, чем в централизованной системе.

/Для решения проблемы обычно выбирается стратегия первичной копии, схематиче- ски описанная выше, в разделе "Распространение обновлений". Для данного объекта А узел, содержащий первичную копию объекта А, будет обрабатывать все операции блоки- ровки для этого объекта (напомним, что первичные копии различных объектов будут в общем случае размещаться на различных узлах). При использовании этой стратегии на- бор всех копий объекта можно рассматривать как отдельный объект для блокировки, а общее количество сообщений будет сокращено с 5л до 2л+3 (один запрос блокировки, одно разрешение блокировки, л обновлений, л подтверждений и один запрос на снятие блокировки). Однако обратите внимание, что это решение влечет за собой серьезную по- терю независимости — транзакция может теперь не завершиться, если первичная копия окажется недоступной, даже если в транзакции выполнялось лишь чтение и локальная копия была доступна. (Отметим, что блокировка первичной копии требуется не только для операций обновления, но и для операций выборки [20.15]. Таким образом, у страте- гии первичной копии есть нежелательный побочный эффект — снижение уровня произ- водительности и доступности как для выборки, так и для обновления.)

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

1. Агент транзакции Т2 на узле X ожидает, пока агент транзакции Т1 на узле X отменит блокировку.

2. Агент транзакции Т1 на узле X ожидает, пока агент транзакции Т1 на узле Y завер- шит транзакцию.

3. Агент транзакции Tl на узле Y ожидает, пока агент транзакции Т2 на узле Y отменит блокировку.

4. Агент транзакции Т2 на узле Y ожидает, пока агент транзакции Т2 на узле X завер- шит транзакцию. Взаимная блокировка!

СайтХ

Удерживает блокировку Lx