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

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

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

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

п сообшений об обновлении;

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

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

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

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

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

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

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

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

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

СайтХ

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

Транзакция Tlx

Ожидает завершения транзакции Т1у

Ожидает снятия блокировки Lx транзакцией Т1х

Транзакция Т2х

Транзакция Т1х

Ожидает снятия блокировки Ly транзакцией Т2у

Ожидает завершения транзакции Т2х

Транзакция Т2х

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

Сайту

Рис 20.6 Пример состояния глобачьной взаимной блокировки

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

Изящная (и распределенная) схема для определения состояния глобальной блокировки описана в статьях о системе R* (например, [20.39]).

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

20.5. Cncxeivibi клиент/сервер

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

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

Напомним (см. главу 2), что термин клиент/сервер подразумевает, прежде всего, архитектуру, или логическое разделение обязанностей. Клиент- это приложение, которое также называют приложением переднего плана (frontend), а сервер- это СУБД или приложение заднего плана (backend). Однако именно потому, что всю систему можно так четко разделить на две части, появилась возможность выполнения ее частей на разных машинах. И эта возможность по многим причинам оказалась настолько заманчивой (см. главу 2), что термин клиент/сервер на практике подразумевает исключительно случай, когда клиент и сервер действительно размешаются на разных машинах *. Хотя это и небрежное использование термина, однако оно широко распространено, и поэтому мы будем его придерживаться.

Напомним, что возможны несколько вариантов основной схемы.

Приложения

Компьютер клиента

Прозрачный удаленный доступ

СУБД

Компьютер сервера

Рис. 20.7. Система клиент/сервер

Несколько клиентов могут совместно использовать один и тот же сервер (фактически это обычная практика).

Отдельный клиент может иметь доступ к нескольким серверам. Эта возможность, в свою очередь, делится на два случая.

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

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

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

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