Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 96
Текст из файла (страница 96)
Эти службы, которые, в сущности, предлагают наборсерверов (более менее статический), разбросанных по всему Интернету, поддерживают и предоставляют доступ к web-файлам, принадлежащим третьим лицам.Для улучшения качества услуг эти службы хостинга могут динамически реплицировать файлы на те серверы, для которых такая репликация вызовет увеличение производительности, то есть поближе к клиентам или группам клиентов.Одна из проблем реплик, создание которых инициировано сервером, состоитв необходимости принятия решения о том, где и когда будут создаваться и уничтожаться эти реплики.
Подход к динамической репликации файлов в случаеслужб web-хостинга описан в [365]. Алгоритм разработан для поддержки webстраниц и поэтому предусматривает относительно редкие, по сравнению с запросами на чтение, обновления. В качестве модулей данных используются файлы.Основу функционирования алгоритма динамической репликации составляютдва положения. Во-первых, репликация должна производиться для уменьшениянагрузки на сервер. Во-вторых, конкретные файлы с сервера должны перемещаться или реплицироваться на серверы, расположенные как можно ближе кклиентам, от которых исходит множество запросов на эти файлы.
Далее мы сосредоточимся только на втором положении. Мы также опустим множество деталей, которые можно найти в [365].Каждый сервер подсчитывает число обращений к файлам и отслеживает, откуда приходят эти обращения. В частности, это означает, для данного клиента Скаждый сервер может определить, какой из серверов службы web-хостинга к нему ближе всего (эта информация может быть получена, например, из баз данныхмаршрутизации). Если клиент С\ и клиент Сг совместно используют один и тотже «ближайший» сервер Р, все запросы на доступ к файлу JF на сервере Q от Ci иСг будут зарегистрированы на Q в едином счетчике обращений cntQ(P,F).
Этакартина показана на рис. 6.19.Когда число запросов на конкретный файл F на сервере S упадет ниже порогаудаления del(S,F), файл будет удален с сервера S. Соответственно, число реплик368Глава 6. Непротиворечивость и репликацияэтого файла уменьшится, что, возможно, приведет к росту нагрузки на другиесерверы. Для того чтобы гарантировать наличие в сети хотя бы одной копиифайла, принимаются специальные меры.Сервер без копиифайла FСервер с копиейфайла FФайл FСервер Q подсчитывает обращенияот клиентов C-i и Сг, пришедшие с сервера РРис.
6.19. Подсчет числа обращений от различных клиентовПорог репликации rep(S,F), выбираемый всегда выше порога удаления, указывает на то, что число обращений к конкретному файлу настолько высоко, чтоего стоит реплицировать на другой сервер. Если число запросов находится гдето между порогами репликации и удаления, файл можно только переместить.Другими словами, в этом случае необходимо как минимум сохранить число реплик этого файла неизменным.Когда сервер Q решает переопределить местоположение хранимых файлов,он проверяет счетчики обращений для каждого файла. Если общее число обращений к файлу Fm Q упало ниже порога удаления del(Q,F), он удаляет Fy еслитолько это не последняя его копия. Кроме того, если для какого-либо сервера Рзначение счетчика cntQ(P,F) превышает половину всех запросов к f на Q, сервер Рзапрашивается на предмет переноса на него копии F.
Другими словами, сервер Qбудет пытаться перенести файл F на сервер Р.Перенос файла F на сервер Р может не быть успешным, например, из-за того,что сервер Р и так уже сильно загружен или на нем отсутствует место на диске.В этом случае сервер Q попытается перенести файл F на другой сервер. Разумеется, репликация может производиться только в том случае, если общее числозапросов к jFna (2 будет выше порога репликации rep(QyF). Сервер Q проверитвсе остальные серверы службы web-хостинга, начиная с наиболее удаленных. Если для некоторого сервера R значение счетчика cntQ(R,F) превзойдет некоторуюдолю всех запросов к файлу F на сервере Q, будет сделана попытка реплицировать F на R.Инициируемая сервером репликация постепенно становится все популярнее,особенно в контексте служб web-хостинга, которые были описаны.
Отметим, чтоесли мы гарантируем, что каждый элемент данных всегда хранится как минимумна одном сервере, мы можем ограничиться только инициируемой сервером репликацией, вообще отказавшись от постоянных реплик. Тем не менее постоянныереплики продолжают активно использоваться в системах резервного копирования, а также как единственные реплики, гарантирующие сохранение непротиво-6.4. Протоколы распределения369речивости данных при внесении изменений. При наличии таких постоянных реплик инициируемые сервером реплики затем используются для максимальногоприближения к клиентам копий, предназначенных только для чтения.Реплики, инициируемые клиентомЕще один важный тип реплик — реплики, создаваемые по инициативе клиентов.Инициируемые клиентом реплики часто называют клиентскими кэшами {clientcaches), или просто кэшами {caches).
В сущности, кэш — это локальное устройствохранения данных, используемое клиентом для временного хранения копии запрошенных данных. В принципе управление кэшем полностью возлагается наклиента. Хранилище, из которого извлекаются данные, не делает ничего для поддержания непротиворечивости кэшированных данных. Однако, как мы увидим,существует множество случаев, в которых клиент полагается на то, что хранилище данных известит его об устаревании кэшированных данных.Клиентский кэш используется только для сокращения времени доступа кданным. Обычно, когда клиент хочет получить доступ к некоторым данным, онсвязывается с ближайшим хранилищем с их копией и считывает оттуда данные,которые хочет считать, или сохраняет туда данные, которые он только что изменил.
Производительность большинства операций, включающих только чтениеданных, можно повысить, указав клиенту на необходимость сохранять запрошенные данные в близко расположенном кэше. Такой кэш может располагатьсяна машине клиента или на отдельной машине в той же локальной сети, что и машина клиента. Когда клиенту в следующий раз потребуется считать те же самыеданные, он просто получит их из локального кэша. Эта схема отлично работает,если в промежутке между запросами данные не менялись.Время хранения данных в кэше обычно ограничивается, например, чтобыпредотвратить фатальное устаревание информации или просто освободить местодля новых данных.
Если запрашиваемые данные могут быть извлечены из локального кэша, говорят, что произошло кэш-попадание {cache hit). Чтобы повысить число кэш-попаданий, кэш может совместно использоваться несколькимиклиентами. Основой для этого служит предположение о том, что данные, запрошенные клиентом Си могут потребоваться также и другому расположенному рядом с ним клиенту Сг.Насколько это предположение верно, в значительной степени зависит от типахранилища данных. Так, например, в традиционных файловых системах файлывообще редко используются совместно [68, 308], и создание общего кэша бесполезно.
С другой стороны, общий кэш web-страниц оказывается очень полезным,хотя вносимый им рост производительности постепенно сходит на нет по причине того, что сайтов, совместно используемых различными клиентами, становитсявсе меньше по сравнению с общим количеством web-страниц [38].Размещение клиентского кэша — дело относительно несложное. Обычно кэшрасполагается на той же машине, что и клиент, или на совместно используемойклиентами машине в одной с ними локальной сети. Однако в некоторых случаяхсистемные администраторы применяют дополнительные уровни кэширования.370Глава 6.
Непротиворечивость и репликациявводя кэш, совместно используемый множеством отделов или фирм, или дажесоздавая общий кэш для целых регионов — провинций или стран.Еще один подход к кэшированию — поместить серверы (кэши) в определенных точках глобальной сети и позволить клиенту найти ближайший. Когда сервер найден, ему посылается запрос на сохранение данных, которые клиент откудато получил, как описывается в [318]. Позже в этой главе мы вернемся к кэшированию при описании протоколов непротиворечивости.6.4.2. Распространение обновленийОперации обновления в распределенных и реплицируемых хранилищах данныхобычно инициируются клиентом, после чего пересылаются на одну из копий. Оттуда обновление распространяется на остальные копии, гарантируя тем самымсохранение непротиворечивости.
Как мы увидим далее, существуют различныеаспекты проектирования, связанные с распространением обновлений.Состояние против операцийОдин из важных вопросов проектирования заключается в том, что же именно мысобираемся распространять. Существует три основных возможности:4^ распространять только извещение об обновлении;4- передавать данные из одной копии в другую;4- распространять операцию обновления по всем копиям.Распространение извещения производится в соответствии с протоколами онесостоятельности {invalidation protocols).
Согласно протоколу о несостоятельности другие копии информируются об имевшем место обновлении, а такжео том, что хранящиеся у них данные стали неправильными. Эта информация может определять, какая именно часть хранилища данных была изменена, то естькакая часть данных перестала соответствовать действительности. Важно отметить, что при этом не передается ничего кроме извещения. Независимо от требуемой для неправильной копии операции, обычно сначала нужно обновить этукопию. Конкретные действия по обновлению зависят от поддерживаемой модели непротиворечивости.Основное преимущество протоколов о несостоятельности в том, что они используют минимум пропускной способности сети. Единственная информация,которую необходимо передавать, — это указание на то, какие данные стали неправильными.
Протоколы о несостоятельности обычно прекрасно работают прибольшем, по сравнению с операциями чтения, количестве операций записи, тоесть в условиях, когда отношение операций чтения к операциям записи относительно невелико.Рассмотрим, например, хранилище данных, в котором обновления распространяются путем рассылки обновленных данных всем репликам. Если размеробновленных данных велик, а обновления, по сравнению с операциями чтения,происходят часто, мы можем столкнуться с ситуацией, когда два обновленияпроисходят одно за другим так, что в промежутке между ними операции чтения6.4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
