Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

11.4. Итоги 751

Почему при наличии сохранных соединений производительность значитель-

но выше по сравнению с несохранными соединениями?

Объясните разницу между модулями расширения, апплетами, сервлетами

и программами CGI.

Опишите структуру службы именования общего назначения, преобразующей

URN в URL, то есть службы, которая разрешает имя URN в указатель URL

копии документа, идентифицируемого именем URN.

6. Достаточно ли клиенту в системе WebDAV для получения права на запись

предъявить серверу только маркер блокировки?

Несмотря на то что web-заместитель вычисляет время истечения срока годно-

сти документа, это независимо от него делает еще и сервер. В чем достоинст-

во такого подхода?

8. Какому протоколу распространения соответствует сеть CDN Akamai

—

извле-

чения или продвижения?

9. Опишите простую схему, при использовании которой сервер CDN Akamai мо-

жет, не проверяя документ на исходном сервере, обнаружить, что срок годно-

сти кэшированного документа истек.

10.

Имеет ли смысл вместо использования одной или нескольких глобальных

стратегий репликации поддерживать собственную стратегию репликации для

каждого web-документа?

И. URL в Notes содержит идентификатор документа. Насколько это лучше по

сравнению с использованием в URL имен файлов, как это принято в Web?

12.

Предполагает ли схема URL в Notes глобально уникальные имена операций?

13.

Рассмотрим кластер серверов Domino и предположим, что клиент Notes в пер-

вый раз связался с сильно загруженным сервером Domino этого кластера.

Опишите дальнейшее развитие событий.

14.

В этой главе был описан конфликт между двумя измененными документами

Notes.

Возможно также возникновение конфликта между удаленной и изме-

ненной копиями. Опишите, как возникает подобный конфликт и как его мож-

но разрешить.

15.

Какова вероятность конфликта двойной записи в Notes для случая реплика-

ции в кластере?

16.

Приведите решение по аутентификации в Notes, альтернативное использова-

нию перекрестных сертификатов.

17.

Выполнение загруженного кода в Notes часто базируется на доверии. Насколь-

ко это безопасно?

Глава 12

Распределенные

системы согласования

12.1.

Знакомство с моделями согласования

12.2.TIB/Rendezvous

12.3.

Jini

12.4.

Сравнение TIB/Rendezvous и Jini

12.5.

Итоги

В предыдущих главах мы рассматривали различные подходы к распределенным

системам, в которых в качестве субъекта распределения присутствовал некий тип

данных. Этот тип данных

—

объект, файл или документ

—

является, по сути, по-

рождением нераспределенных систем, который адаптируется для распределен-

ных систем таким образом, чтобы многие проблемы, вызываемые распределен-

ной архитектурой, были незаметны ни полызователям, ни разработчикам.

В этой главе мы рассмотрим новое поколение распределенных систем, кото-

рые изначально предполагают распределенность многих компонентов системы,

и реальные проблемы таких систем вытекают из необходимости согласовывать

взаимодействие разных компонентов. Другими словами, вместо того чтобы ре-

шать проблемы прозрачного распределения компонентов, мы сосредоточимся на

согласовании этих компонентов.

Некоторые вопросы согласования уже рассматривались в предыдущих гла-

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

многие традиционные распределенные системы постепенно включаются механиз-

мы,

играющие ключевую роль в системах согласования.

Перед тем как рассматривать практические примеры систем, мы познакомим-

ся с моделями согласования и самим понятием согласования в распределенных

системах. Затем мы обсудим две системы согласования: Rendezvous Bus компа-

нии TIBCO

Jini компании Sun Microsystems. Эти примеры помогут нам понять

особенности многих распределенных систем согласования, существующих реаль-

но или виде исследовательских проектов.

12.1.

Знакомство с моделями согласования 753

12.1.

Знакомство с моделями

согласования

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

отделение собственно вычислительных процессов от механизмов их согласова-

ния. Если рассматривать распределенную систему как набор процессов (возмож-

но,

многопоточных), то станет понятно, что вычислительная часть распределен-

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

конкретные вычислительные операции, причем эти операции в принципе могут

выполняться независимо от других процессов.

ЭТ0Р1

модели согласующая часть распределенной системы поддерживает все

взаимодействие между процессами и организует их взаимную кооперацию. Она

образует тот «клей», который связывает воедино деятельность, выполняемую раз-

ными процессами

[164].

В распределенных системах согласования основное вни-

мание уделяется согласованию процессов.

В [79] представлены результаты таксономии моделей согласования мобиль-

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

гим типам распределенных систем. Адаптируя приведенную там терминологию

к распределенным системам в целом, можно разделить модели по двум измере-

ниям ~ времени и ссылкам, как показано на рис. 12.1.

Время

Связное Несвязное

Связные Прямое согласование Согласование через

Ссылки почтовый ящик

Несвязные Согласование на встрече Генеративная связь

Рис. 12.1. Таксономия моделей согласования

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

сование осуществляется напрямую. Назовем его прямым

согласованием

{direct

coordination).

Связность ссылок обычно имеет вид явной идентификации собе-

седника в процессе взаимодействия. Так, например, процесс может взаимодейст-

вовать с другим процессом только в том случае, если он знает идентификатор

процесса, с которым хочет обменяться информацией. Временная связность озна-

чает, что оба взаимодействующих друг с другом процесса активны одновремен-

но.

Такая связность имеет место при нерезидентной связи на основе сообщений,

которую мы рассматривали в главе 2.

Другой тип согласования наблюдается в том случае, если процессы не связа-

ны по времени, но связаны по ссылкам. Мы будем называть его

согласованием

через

почтовый

ящик {mailbox

coordination).

В этом случае для взаимодействия

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

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

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

аналогична сохранной связи на основе сообщений, которую мы также рассмат-

754 Глава 12. Распределенные системы согласования

ривали в главе 2. При этом необходимо явно указать адрес почтового ящика,

в котором должны храниться сообщения. Это, собственно, и есть ссылочная

связность.

Комбинация связности по времени и несвязности по ссылкам образует груп-

пу моделей

согласования

па

встрече {meeting-oriented

coordination).

В несвязной

по ссылкам системе процессы не имеют полной информации друг о друге. Дру-

гими словами, когда процесс хочет согласовать свою деятельность с другими про-

цессами, он не может обратиться к ним напрямую. Взамен используется метафора

встречи, на которой собираются процессы, чтобы скоординировать свою дея-

тельность. Модель предполагает, что процессы, участвующие во встрече, выпол-

няются одновременно.

Системы согласования на встрече часто реализуются на базе событий, схожих

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

мы рассмотрим другой механизм реализации встреч, реализуемый так называе-

мыми

системами

публикации/подписки

{publish/subscribe

systems). В этих систе-

мах одни процессы могут подписываться на сообщения, содержащие информа-

цию по определенной теме, а другие процессы

—

публиковать (то есть создавать)

такие сообщения. Большинство систем публикации/подписки требуют, чтобы

взаимодействующие процессы были активны одновременно, следовательно, они

связаны по времени. Однако взаимодействующие таким образом процессы могут

оставаться неизвестными друг другу.

Наиболее широко известный вариант согласования

—

это сочетание несвяз-

ных по времени и по ссылкам процессов, представленный

генеративной

связью

{generative communication), которая впервые была реализована в программной

системе Linda

[163].

Основная идея генеративной связи состоит в том, что набор

независимых процессов может использовать разделяемое сохранное пространст-

во данных, организуемое с помощью кортежей. Кортежи

—

это именованные за-

писи, содержащие несколько (но, возможно, и ни одного) типизованных полей.

Процесс может помещать в разделяемое пространство данных записи любого ти-

па (то есть генерировать связующие записи). В отличие от электронных досок

объявлений, в этом случае нет необходимости точно задавать структуру корте-

жей. Для разделения кортежей в соответствии с информацией, которая в них со-

держится, достаточно их имен.

Интересная особенность этих разделяемых пространств имен состоит в том,

что они реализуют механизмы ассоциативного поиска кортежей. Другими слова-

ми,

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

определить значения полей, которые его интересуют. Любой кортеж, удовлетво-

ряющий описанию, будет извлечен из пространства данных и передан процессу.

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

редного кортежа. Мы отложим детальное описание этой модели согласования до

обсуждения системы Jini. В [106] представлен обзор моделей генеративной свя-

зи в контексте приложений для Интернета.

Большинство исследований по вопросам согласования в основном посвящено

программным моделям и соответствующим языкам

[341].

Более поздние иссле-

12.2.

TIB/Rendezvous 755

дования относятся к следующему уровню абстракции

—

архитектуре программ и

систем [41, 161]. Один из важных вопросов в архитектуре программ и систем

—

отделение компонентов от механизмов их взаимодействия. Это отделение при-

водит к понятию архитектурного стиля и языков описания архитектуры. Допол-

нительную информацию по этим темам можно найти в [289, 411].

12.2.

TIB/Rendezvous

В качестве первого примера распределенной системы согласования мы рассмот-

рим систему TIB/Rendezvous, разработанную компанией TIBCO. Обзор этой сис-

темы можно найти в

[460];

детали ее строения описаны в разнообразных техниче-

ских руководствах,

ВХОДЯЩР1Х

В комплект поставки.

12.2.1.

Обзор

Система TIB/Rendezvous [323, 423] изначально была описана в понятиях инфор-

мационной шины {infoimation bus), минимальной коммуникационной системы

группы процессов, основанной на следующих принципах. Во-первых, степень за-

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

например, из ядра полностью ргсключена сложная семантика упорядочения сооб-

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

уровне [99]. Мы касалр1сь этого вопроса в главе

Точно так же в базовой системе

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

поддержка может быть реализована при помощи дополнительной службы.

Второй принцип построения системы состоит в том, что сообщения описыва-

ют себя сами. На практике это означает, что приложение может проверить вхо-

дящее сообщение, чтобы определить, какова его структура и какие данные оно

содержит. Заметим, что в противоположность этому правилу в большинстве

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

мате входящих сообщений и ему остается лишь верно рштерпретировать их со-

держание.

Третий принцип построения заключается в том, что процессы не имеют ссы-

лочной связности. Причина введения этого принципа вызвана тем, что обслужи-

вание работающей системы не должно вести к ее остановке, а также необходимо-

стью упростить добавление новых процессов «на лету». Эти требования проще

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

друга. Ссылочная несвязность обеспечивается путем использования адресации

по теме, о которой мы поговорим далее.

Модель согласования

Система TIB/Rendezvous основана на такой модели согласования, когда процес-

сы в основном не обладают ссылочной связностью, но могут получать ее на

короткий срок. Как говорилось выше, эта модель напоминает согласование на

встрече. Кроме того, система предоставляет также службу, при помощи которой

756 Глава 12. Распределенные системы согласования

процессы получают возможность оставаться несвязными по времени. Детали этой

модели будут рассмотрены позже.

Ключевой механизм, лежащий в основе модели согласова1Н1я TIB/Rende-

ZVOUS,

— это адресация по теме {subject-based addressing). При таком подходе

процесс, который собирается посылать сообщение, не может определить точное

место назначения. Вместо этого он именует сообщение названием темы {subject

пате),

после чего посылает его в коммуникационную систему для пересылки по

сети.

Получатели, в свою очередь, не выясняют, от каких процессов они собирают-

ся получать сообщения. Вместо этого они сообщают коммуникационной систе-

ме,

какие темы их интересуют. Коммуникационная система гарантирует, что по-

лучателю будут доставлены только те сообщения, которые несут данные по теме,

интересующей получателя.

Отправка сооби].ения методом адресации по теме также называется публика-

цией {publishing). Чтобы получить сообщение по определенгюй теме, процесс дол-

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

писки, использующих метод адресацрно по теме, показаны на рис. 12.2.

1 Публикация

на тему А

|Тема:А|

Библиотека

1 RV-демон 1

^ \

на тему А

Библиотека

RV-демон 1

на тему А

Публикация

на тему В

Д [Тема: в]

Библиотека I

1 RV-демон ;

)

Групповая рассылка /

по теме А подписчикам

на тему А

на тему В

^ 1

Библиотека!

; RV-демон 1

)

на тему А

{Библиотека

RV 1

RV-демон 11

Сеть

Групповая рассылка по теме В подписчикам

Рис. 12.2. Принципы организации системы публикации/подписки,

реализованной в TIB/Rendezvous

Архитектура

Архитектура системы TIB/Rendezvous относительно проста. Ее основой являет-

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

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

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

общений. На каждом узле этой сети работает демон контактов {rendezvous dae-

mon),

который отвечает за то, чтобы сообщения отсылались и получались в соот-

ветствии с темой. Когда сообщение публикуется, демон контактов осуществляет

его групповую рассылку всем узлам сети. Обычно групповая рассылка реализует-

12.2.

TIB/Rendezvous 757

ся средствами базовой сети, такими как групповая рассылка по IP-адресам или

аппаратная широковещательная рассылка.

Процессы, подписываясь на определенную тему, передают свою подписку ло-

кальному демону. Демон создает таблицу пар

{процесс,

тема) и при доставке со-

общения с темой S просто просматривает эту таблицу в поисках локальных под-

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

никто не подписался, сообщение немедленно уничтожается.

Чтобы система могла вырасти до размера больших сетей, таких как сети WAN,

используются также маршрутизирующие

демогсы

контактов {rendezvous router

daemons).

Обычно каждая локальная сеть имеет одного маршрутизирующего де-

мона контактов. Этот демон связывается с маршрутизртрующим демоном другой

удаленной сети, как показано на рис. 12.3. Маршрутизирующие демоны образу-

ют сквозную оверлейную сеть {overlay network), в которой маршрутизаторы со-

единены между собой попарно соединениями TCP. Вторичная сеть

—

это сеть

маршрутизаторов прикладного уровня. Мы уже говорили о сетях такого типа,

когда обсуждали системы очередей сообщений в главе 2.

Маршрутизирующий демон

Локальная сеть

Сквозное

соединение TCP

Рис. 12.3. Общая архитектура глобальной сети

TIB/Rendezvous system

Каждый маршрутизатор знает топологию вторичной сети и вычисляет дерево

групповой рассылки для публикации сообщений в других сетях. Маршрутизато-

ры рассылают только те сообщения, которые публикуются в их локальной сети.

Сообщения из других сетей пересылаются по дереву групповой рассылки той се-

ти,

из которой они первоначально исходили.

В целях повышения производительности всякий раз при публикации сообще-

ния оно доставляется только в те удаленные сети, которые были сконфигуриро-

ваны на прием подобных сообщений и имеют текущих подписчиков этих сооб-

щений. Детали такого рода ограничений мы рассмотрим ниже.

758 Глава 12. Распределенные системы согласования

12.2.2.

Связь

Основой системы TIB/Rendezvous являются ее средства связи. Мы уже познако-

мились с работой механизма передачи сообщений, а теперь рассмотрим детали

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

связи. Идеология публикации/подписки хорошо сочетается с программировани-

ем на базе событий, которое TIB/Rendezvous поддерживает. О событиях мы так-

же поговорим в этом разделе.

Основы передачи сообщений

Как мы говорили, связь в TIB/Rendezvous осуществляется путем отправки и по-

лучения самоопределяющихся сообщений с использованием адресации по теме.

Каждое сообщение содержит несколько (или ни одного) полей, динамически соз-

данных процессом-отправителем. Сами поля представляют собой записи с атри-

бутами, перечисленными в табл. 12.1.

Таблица 12.1. Атрибуты полей сообщения TIB/Rendezvous

Атрибут Тип Описание

Имя поля, возможно, NULL

Уникальный номер поля в сообщении

Общий размер поля (в байтах)

Число элементов в случае массива

Константа, идентифицирующая тип данных

Некоторые данные, хранящиеся в поле

Каждое поле обычно имеет строковый атрибут Name, который представляет

собой просто имя поля. Различные поля одного сообщения могут иметь одина-

ковые имена. Можно также при помощи атрибута ID сопоставить каждому полю

сообщения отдельный идентификатор поля. Идентификатор поля

—

это 2-бай-

товое целое число, которое должно быть уникальным для каждого поля сооб-

щения.

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

Size.

В том случае, если поле содержит массив, в атрибуте Count хранится число

элементов массива.

Атрибут Туре

—

это константа, соответствующая одному из простых типов

данных TIB/Rendezvous. Если в поле хранится массив, атрибут Туре содержит

тип элементов массива. TIB/Rendezvous предоставляет также средства для обме-

на данными с произвольным пользовательским типом. И наконец, атрибут Data

содержит собственно данные, хранящиеся в поле.

Каждое сообщение может содержать произвольное число полей. Перед тем

как сообщение будет отослано, необходимо указать его тему, чтобы операции от-

бора правильно обрабатывали это сообщение. Сама по себе тема выглядит как

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

ответ на другое сообщение. Это название темы может быть использовано полу-

Name

Size

Count

Type

Data

String

Integer

Константа

Любой тип

12.2.

TIB/Rendezvous 759

чателем для ответа процессу, отправившему исходное сообщение. Разумеется,

отправитель считается подписанным на ответы на свое сообщение.

В целях повышения производительности каждый процесс может использо-

вать специально созданное имя темы, называемое именем входа (inbox пате). Это

имя зависит от процесса. Если издатель Р использует при публикации сообще-

ния имя входа другого процесса Q, это сообщение будет послано Q напрямую

средствами сквозной связи, а не групповой рассылки.

Для отправки и приема сообщений процессы создают так называемые транс-

порты. Транспорт {transpoit)

—

это локальный объект, подобный сокетам Беркли

в UNIX, о которых мы говорили в главе 2. Транспорт используется для отправки

сообщений демонам контактов, прослушивающим определенный порт, по одному

из стандартных протоколов связи. Так, например, существуют различные транс-

порты для широковещательных рассылок, групповых рассылок канального уров-

ня,

групповых рассылок по IP-адресам.

Транспорт в состоянии выполнять лишь три простейших операции. Опера-

ция send передает сообщение локальному демону контактов, который, в свою оче-

редь,

отвечает за корректную ее публикацию. Операция send является неблоки-

рующей.

Также неблокирующей является операция sendreply, которая может вызы-

ваться в ответ на получение ответного сообщения, о котором мы говорили чуть

выше.

И, наконец, существует блокирующая операция sendrequest, которая посылает

локальному демону контактов сообщение для передачи по базовой сети и блоки-

руется до получения ответного сообщения. Ответ передается на имя входа (соз-

данное динамически) средствами сквозной связи.

Отметим, что специальной операции receive не существует. Как мы покажем

далее, ответ на сообщение обычно обрабатывается при помощи стандартных

средств обработки сообщений. Когда приходит сообщение по той теме, на кото-

рую процесс подписан, система событий TIB/Rendezvous вызовет функцию об-

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

подхода мы рассмотрим позже.

События

Для того чтобы получать сообщения по темам, на которые данный процесс был

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

обрабатывать входящие сообщения нет. Операция sendrequest представляет со-

бой исключение из этого правила.

Подписка на тему осуществляется посредством создания слушателя событий

{listener event). Слушатель событий представляет собой локальный объект, соот-

ветствующий способу доставки и теме, на которую подписан создавший его про-

цесс.

Слушатель событий также содержат ссылку на функцию обратного вызова,

которую предоставляет подписчик. Эта функция вызывается при диспетчериза-

ции {dispatching) события. Диспетчеризация событий для входящих сообщений

происходит в соответствии со схемой на рис. 12.4.

760 Глава 12. Распределенные системы согласования

Пользовательская

функция обратного вызова

^ и ^

Созданные

пользователем

слушатели событий

Очередь

событий

Слушатель

событий А

Слушатель

событий В

О-"

а--"

а---

А"

Ссылка

на обратный

вызов

Проверка

подписки

Создание и постановка

в очередь объекта события

Входящее сообщение

Рис. 12.4. Обработка подписок слушателем событий в TIB/Rendezvous

Приложение

пользователя

Промежуточный

уровень

TIB/Rendezvous

Локальная

операционная

система

Когда приходит сообщение, тема которого соответствует теме, указагнюй в слу-

шателе событий порта, создается и включается в локальную очередь событий

системы TIB/Rendezvous объект события {event object). Такой объект события

содержит ту же рп1формацию, что и слушатель событий. Последний используется

для прослушивания большинства входящих сообщений. Каждая очередь собы-

тий имеет как минимум один соответствующий ей поток диспетчеризации, кото-

])bn'i удаляет событие из верхушки очереди, после чего вызывает нужную функцию

обратного вызова. При вызове этой функции передается входящее сообщение,

соответствующее прошедшему диспетчеризацию событию.

Если приходит очередное сообщение с темой, указанной в слушателе собы-

тий, то создается и добавляется в локальную очередь другой объект события. При

этом не имеет значения, ожидает ноток диспетчеризации прихода нового объек-

та события или занят обработкой предыдущего. Чтобы отменить подписку, под-

1П1санный процесс должен лишь удалить соответствующий слушатель событий.

Любые ожидающие обработки объекты событий, ассоциированные с этим слу-

шателем, также будут уничтожены. Рисунок 12.5 иллюстрирует процедуру обра-

ботки трех входящих сообщений, соответствующих одному слушателю событий.

Каждая горизонтальная линия соответствует временному тгнтервалу, занимаемо-

му подпиской или обработкой сообщения.

Здесь следует сделать важное замечание. Если входящее сообщение имеет те-

му, указанную в двух или более слушателях событий, то каждый из них создает

соответствующий об1^ект события и добавляет его в очередь. Другими словами,

одно входящее сообщение ведет к появлению несколькргх объектов событий.

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

ко,

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

ко очередей событий и явно распределить события по этим очередям. Наличие