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

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

6.4. Протоколы распределения 371

отсутствуют. Соответственно, распространение первого обновления на все реп-

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

обновлением. Вместо этого мы можем послать извещение о том, что данные бы-

ли обновлены, и это будет значительно быстрее.

Передача обновленных данных между репликами

—

это вторая альтернатива,

она применяется, когда отношение операций чтения к операциям записи относи-

тельно велико. В этом случае высока вероятность того, что обновление окажется

эффективным в том смысле, что модифицированные данные будут прочитаны

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

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

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

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

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

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

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

ет произвести. Этот метод, называемый также

активной

репликацией {active rep-

lication),

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

«активно» сохранять актуальность своих данных путем выполнения операций

над ними

[403].

Основной выигрыш от активной репликации состоит в том, что

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

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

операцией, относительно немного. С другой стороны, каждой реплике может по-

требоваться большая процессорная мощность, особенно если операции окажутся

сложными.

Продвижение против извлечения

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

(push) или извлекать (pull). В протоколах, основанных на

продвижении

{push-

based

protocols),

известных также под названием серверных

протоколов

{server-

based

protocols),

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

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

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

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

кэши. Серверные протоколы применяются, когда в репликах в основном следует

поддерживать относительно высокий уровень непротиворечивости. Другими сло-

вами, когда реплики должны быть идентичными.

Требование высокой степени непротиворечивости связано с тем фактом, что

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

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

ществляют в основном операции чтения. Соответственно, соотношение опера-

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

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

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

пользователями. Кроме того, протоколы продвижения делают непротиворечи-

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

372 Глава 6. Непротиворечивость и репликация

В противоположность им, в подходах, основанных на извлечении (pull-based

approach),

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

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

на извлечении, называемые клиентскими протоколами (client-based

protocols),

часто используются при работе с клиентским кэшем. Так, например, стандартная

стратегия, применяемая при работе с кэшами в Web, предполагает предвари-

тельную проверку актуальности кэшированных данных. Когда кэш получает за-

прос на локально кэшированный элемент данных, он обращается к «родному»

web-серверу, проверяя, не был ли этот элемент данных модифицирован после

его кэширования. В том случае, если модификация имела место, модифициро-

ванные данные передаются сначала в кэш, а затем

—

запросившему их клиенту.

Если модификации не было, клиенту сразу передаются кэшированные данные.

Другими словами, клиент опрашивает сервер в поисках обновлений.

Метод извлечения эффективен при относительно небольшом отношении коли-

чества операций чтения к количеству операций записи. Такая ситуация характер-

на для клиентских кэшей, с которыми работает только один клиент (не разделяе-

мых).

Однако даже в том случае, когда кэш совместно используется множеством

клиентов, подход, основанный на извлечении, может быть весьма эффективен

—

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

недостаток этой стратегии по сравнению с продвижением состоит в том, что в

случае

кэш-промаха

(cache

miss),

то есть когда данные в кэше оказываются неак-

туальными, время отклика увеличивается.

При сравнении подходов, основанных на извлечении и продвижении, можно

отметить множество нюансов, часть которых иллюстрирует табл. 6.7. Для про-

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

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

торых использует собственный кэш.

Таблица 6.7. Сравнение протоколов извлечения и продвижения для системы

с одним сервером и несколькими клиентами

Аспект Продвижение Извлечение

Информация Список клиентских реплик Ничего

о состоянии на сервере и кэшей

Содержание сообщений Обновление (и, возможно, Запрос и обновление

сначала запрос)

Время отклика для клиента Немедленно (или, в случае Время получения обновления

запроса, время получения

обновления)

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

продвижении, является необходимость отслеживать все клиентские кэши. Даже

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

ей состояния обычно менее устойчивы к сбоям, отслеживание всех клиентских

кэшей может создать серьезную нагрузку на сервер. Например, при подходе, ос-

нованном на продвижении, web-серверу просто придется помнить о каждом из

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

6.4. Протоколы распределения 373

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

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

всем найденным клиентам. Более того, если клиент в поисках свободного места

на диске выбросит страницу из своего кэша, он должен будет уведомить об этом

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

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

личны. При продвижении единственный тип взаимодействия

—

обновления, пе-

редаваемые сервером клиенту. Если в качестве обновлений фигурируют только

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

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

клиент должен опрашивать сервер и в случае необходимости получать модифи-

цированные данные.

И, наконец, время отклика для клиента также будет различным. Когда сервер

продвигает модифицированные данные в кэш клиента, понятно, что время от-

клика для клиента будет равно нулю. Если продвигаются только уведомления о

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

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

цированных данных).

Недостатки и достоинства обоих подходов приводят нас к смешанной форме

распространения обновлений, основанной на аренде. Аренда (lease)

—

это обеща-

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

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

сти путем извлечения получает от него модифицированные данные. Клиент мо-

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

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

Аренда изначально была предложена в

[175],

где описан удобный механизм

динамического переключения между стратегиями продвижения и извлечения.

[131] описана гибкая система аренды, позволяющая динамически адаптировать

срок аренды в соответствии с различными критериями. Были выделены следую-

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

обновления продвигаются сервером на клиента):

аренда, основанная на «возрасте» элемента данных;

4 аренда, основанная на том, насколько часто клиент требует обновления

копии в своем кэше;

4 аренда, основанная на объеме дискового пространства, затрачиваемого

сервером на сохранение состояния.

Аренда, основанная на «возрасте» элемента данных, заканчивается для раз-

личных элементов данных в соответствии со временем их последней модифика-

ции. Идея, которая лежит в основе этого решения, состоит в том, что если дан-

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

модифицироваться еще в течение некоторого времени. Для данных в Web это

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

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

ния по сравнению с одинаковыми сроками аренды для всех элементов данных.

374 Глава 6. Непротиворечивость и репликация

Следующий критерий

—

как часто конкретный клиент требует обновления

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

аренды тем клиентам, кэш которых часто обновляется. С другой стороны, кли-

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

ных, получает на этот элемент данных краткосрочную аренду. В результате та-

кой стратегии сервер, в сущности, отслеживает только тех клиентов, которые

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

речивости.

Последний критерий

—

объем пространства, затрачиваемый сервером на сохра-

нение состояния клиентов. Когда сервер понимает, что постепенно «переполня-

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

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

аренды истекает быстро. Другими словами, сервер динамически сокращает объем

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

щаясь в пределе в сервер без фиксации состояния). Это разгружает его, и он на-

чинает работать эффективнее.

Целевая рассылка против групповой

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

—

продвигая или извлекая,

—

тесно

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

—

целевой или групповой. При

целевой

рас-

сылке (unicasting)

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

ния на N'других серверов путем отправки

Л^-

отдельных сообщений, по одному на

каждый сервер. В случае

групповой рассылки (multicasting)

за эффективную пере-

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

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

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

средоточены в пределах одной локальной сети и в наличии имеются аппаратные

средства

широковещательной рассылки

(broadcasting).

Тогда затраты на передачу

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

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

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

но менее эффективной.

Групповая рассылка часто может быть эффективна в сочетании с распростра-

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

«продвинуть» обновление на несколько других серверов, просто использует од-

ну группу групповой рассылки. В противоположность этому, при извлечении об-

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

В этом случае целевая рассылка

—

наиболее эффективное решение.

6.4.3. Эпидемические протоколы

Мы уже упоминали, что для многих хранилищ данных достаточно лишь причин-

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

точно лишь гарантировать причинную идентичность копий. Распространение об-

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

6.4. Протоколы распределения 375

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

эпидемических

прото-

колов (epidemic

protocols).

Эпидемические алгоритмы не разрешают конфликтов

обновления, для этого требуются индивидуальные решения. Вместо этого они

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

меньшего количества сообщений. Для этой цели несколько обновлений часто

объединяются в одно сообщение, которым затем обмениваются два сервера. Эпи-

демические алгоритмы образуют основу системы Bayou, о которой мы говорили

ранее, различные схемы распространения обновлений, использованные в ней,

описаны в

[349].

Чтобы понять основной принцип этих алгоритмов, предположим, что все об-

новления конкретных элементов данных инициируются одним сервером. Таким

образом, мы просто исключаем возможность конфликтов двойной записи. Даль-

нейшее изложение основано на классической статье по эпидемическим алгорит-

мам

[124].

Модели распространения обновлений

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

эпидемий, которая объясняет правила распространения инфекционных заболева-

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

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

лищах данных преследуют также и совершенно иную цель: в то время как органы

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

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

ритмов для распределенных хранилищ данных стараются «заразить» все реплики

обновлениями как можно быстрее.

Используя терминологию эпидемиологов, сервер, являющийся частью рас-

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

инфицированным

{infective), если на нем хра-

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

который еще не получил обновления, называется восприимчивьш {susceptible).

наконец, сервер, данные которого были обновлены, но не готовый или неспо-

собный распространять обновление дальше, называется очищенным {removed).

Одна из популярных моделей распространения — антиэнтропия {anti-

entropy).

Согласно этой модели сервер Р случайным образом выбирает другой

сервер Q, после чего обменивается с ним обновленршми. Существует три способа

обмена обновлениями:

сервер Р только продвигает свои обновления на сервер Q;

4 сервер Р только извлекает новые обновления с сервера Q;

4 серверы Р и Q пересылают обновления друг другу (то есть метод «тяни-

то

лкая»).

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

ся только продвижение обновлений. Интуитивно это можно объяснить следую-

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

могут распространяться только инфицированными серверами. Однако если ин-

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

376 Глава 6. Непротиворечивость и репликация

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

ся друг на друга). Соответственно, имеется шанс на то, что какой-то из серверов

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

что он не был выбран инфицированным сервером.

В противоположность этому, извлечение обновлений при большом количест-

ве инфицированных серверов будет работать гораздо лучше. В этом случае рас-

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

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

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

самому стать инфицированным.

Можно показать, что если изначально инфицирован лишь один сервер, при

использовании любой из форм антиэнторпии обновления потенциально могут

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

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

при помощи которого более или менее инфицированными немедленно станут

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

движение обновления на несколько серверов.

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

распростра-

нением слухов

{rumor

spreading),

или просто

болтовней

{gossiping).

Он работает

следующим образом. Если на сервере Р имеется обновленный элемент данных х,

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

нуть обновление на Q. Однако возможно, что Q У^^ получил это обновление с

другого сервера. В этом случае Р может потерять интерес к дальнейшему распро-

странению обновления, скажем, с вероятностью \/k. Другими словами, он стано-

вится очищенным.

Болтовня полностью соответствует реальной жизни. Если Боб узнает какую-

то «жареную» новость, о которой можно посплетничать, он, скорее всего, позво-

нит своей подружке Алисе и все ей расскажет. Алиса, как и Боб, будет заинтере-

сована в том, чтобы нести эту новость дальше. Однако она может быть разочаро-

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

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

Зачем ей это, если все и так знают ее новость?

Болтовня может быть действительно хорошим способом быстрого распростра-

нения обновлений. Однако оно не гарантирует, что будут обновлены все серверы

[124].

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

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

приР1мчивыми, рассчитывается следующим образом:

Например, при ^ = 3 значение s составляет менее 0,02. Это означает, что вос-

приимчивыми останутся менее 2

серверов. Тем не менее следует принять спе-

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

Комбинирование антиэнтропии с механизмом распространения слухов

—

одна

из таких уловок

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

—

их масштаби-

руемость, вытекающая из того факта, что синхронизировать друг с другом при-

6.5. Протоколы непротиворечивости 377

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

пространения. В [266] показано, что для глобальных систем для получения

лучших результатов имеет смысл учитывать особенности топологии. При этом

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

руют с относительно большей вероятностью. Предполагается, что эти серверы

формируют мостик к другим, удаленным частям системы, а поэтому должны

связываться друг с другом как можно чаще.

Удаление данных

Эпидемические алгоритмы хорошо подходят для распространения обновлений в

причинно непротиворечивых хранилищах данных. Однако у них имеется доволь-

но

странный побочный эффект: затрудненное распространение удалений элемен-

тов

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

данных уничтожает всю информацию об этом элементе. Соответственно, если

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

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

вый элемент.

Хитрость состоит в том, чтобы зафиксировать факт удаления элемента данных

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

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

были обновлены при помощи операции удаления. Запись о произведенном уда-

лении выполняется путем рассылки

свидетельств

о смерти (death certificates).

Разумеется, остается проблема свидетельств о смерти, состоящая в том, что и

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

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

ных с исторической информацией об удаленных элементах данных. В [124]

предложено использовать так называемые спящие свидетельства о смерти. Каж-

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

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

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

о смерти можно удалять.

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

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

спящие свидетельства о смерти, никогда не передавая их дальше. Предположим,

что сервер Р имеет подобное свидетельство на элемент данных х. Если из-за ка-

кой-то случайности на Р придет устаревшее обновление для х, сервер Р отреаги-

рует на это событие просто повторной рассылкой свидетельства о смерти этого

элемента данных.

6.5. Протоколы непротиворечивости

До сих пор мы в основном обсуждали различные модели непротиворечивости и

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

этом разделе

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

378 Глава 6. Непротиворечивость и репликация

и рассмотрим несколько реальных протоколов непротиворечивости. Протокол

непротиворечивости (consistency protocol)

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

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

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

зуемостью. Имеются в виду такие модели, как последовательная непротиворе-

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

атомарные транзакции. В данном разделе мы обсудим различные способы реали-

зации этих моделей непротиворечивости.

Используя ранний подход, описанный в

[440],

протоколы последовательной

непротиворечивости можно классифицировать по тому, существует ли первич-

ная копия данных, которой должны передаваться все операции записи. Если та-

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

ны любой из реплик.

6.5.1.

Протоколы на базе первичной копии

в протоколах на базе первичной копии каждый элемент данных

х,

находящийся в

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

отвечающий за координацию всех операций записи в элемент х. Отличить пер-

вичный элемент данных можно по тому, что он постоянно находится на удален-

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

в котором была инициирована операция записи, эта запись может выполняться

локально.

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

Простейший протокол на базе первичной копии

—

тот, в котором все операции

чтения и записи передаются на удаленный сервер (единственный). В результате

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

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

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

деленным. Работу этого протокола иллюстрирует рис. 6.20. Здесь используются

следующие обозначения:

> W1

—

запрос на запись;

> W2

—

пересылка запроса на сервер;

—

подтверждение выполнения записи;

—

подтверждение выполнения записи;

"¥ R1

—

запрос на чтение;

"¥ R2

—

пересылка запроса на сервер;

"¥ R3

—

возвращение ответа;

4- R4

—

возвращение ответа.

Более интересны с точки зрения непротиворечивости протоколы, которые

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

ции записи должны пересылать на первичную (фиксированную) копию. Подоб-

6.5. Протоколы непротиворечивости 379

ные схемы часто называют [76]

протоколами первичного архивирования

{primary-

backup

protocols).

Как работает протокол первичного архивирования, показано на

рис.

6.21. Здесь используются следующие обозначения:

—

запрос на запись;

—

пересылка запроса на первичный сервер;

—

сигнал на обновление резервных копий;

—

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

—

подтверждение выполнения записи;

—

запрос на чтение;

—

ответ для чтения.

Клиент

Одиночный сервер

для элемента данных х

Сервер резервного

копирования

Хранилище

данных

Рис. 6.20. Протокол удаленной записи на базе первичной копии с фиксированным сервером,

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

Клиент

Первичный сервер

для элемента данных х

Сервер резервного

копирования

Хранилище

данных

Рис. 6.21. Первичное архивирование данных

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

сылает эту операцию на первичный сервер. Первичный сервер осуществляет об-

новление своей локальной копии х, после чего пересылает это обновление серве-

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

посылает обратно первичному серверу свое подтверждение. После обновления

локальных копий всех серверов резервного копирования первичный сервер по-

сылает подтверждение процессу, инициировавшему операцию.

380 Глава 6. Непротиворечивость и репликация

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

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

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

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

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

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

подтверждение. После этого он дает сигнал серверам резервного копирования

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

вичного архивирования обсуждается в [77].

Основная проблема неблокирующего первичного архивирования связана с

защитой от сбоев. В схеме с блокировкой процесс клиента осведомлен о том, что

операция обновления архивируется на несколько других серверов. В случае схе-

мы без блокировки это не так. Мы вернемся к вопросам защиты от сбоев в сле-

дующей главе.

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

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

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

все операции записи в едином порядке, и неважно, какой из серверов резервного

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

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

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

специальных мер, это не гарантировано).

Протоколы локальной записи

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

Первый предполагает наличие единственной копии каждого элемента данных х.

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

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

передается в процесс, после чего производится операция. Этот протокол в основ-

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

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

каждого элемента данных. Работу этого протокола иллюстрирует рис, 6.22. Здесь

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

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

Передача запроса на текущий сервер для элемента данных х.

Перемещение элемента данных х на сервер клиента.

Возвращение результата операции на сервер клиента.

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

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

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

средствами широковещательной рассылки. Альтернативные решения

—

переда-

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

в распределенных системах с разделяемой памятью

[264].

Однако при работе с

крупномасштабными и глобальными хранилищами данных необходимы другие