Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 97
Текст из файла (страница 97)
Протоколы распределения371отсутствуют. Соответственно, распространение первого обновления на все реплики практически бесполезно, поскольку его результаты будут стерты вторымобновлением. Вместо этого мы можем послать извещение о том, что данные были обновлены, и это будет значительно быстрее.Передача обновленных данных между репликами — это вторая альтернатива,она применяется, когда отношение операций чтения к операциям записи относительно велико. В этом случае высока вероятность того, что обновление окажетсяэффективным в том смысле, что модифицированные данные будут прочитаныдо того, как произойдет следующее обновление. Вместо того чтобы распространять обновленные данные, достаточно вести журналы обновлений и для снижения нагрузки на сеть передавать только эти журналы. Кроме того, передачу данных часто можно агрегировать в том смысле, что несколько модификаций можноупаковать в одно сообщение.
Это также снизит затраты на взаимодействие.Третий подход состоит в том, чтобы отказаться от переноса модифицированных данных целиком, а указывать каждой реплике, какую операцию с ней следует произвести. Этот метод, называемый также активной репликацией {active replication), предполагает, что каждая реплика представлена процессом, способным«активно» сохранять актуальность своих данных путем выполнения операцийнад ними [403]. Основной выигрыш от активной репликации состоит в том, чтообновления часто удается распространять с минимальными затратами на взаимодействие, определяемыми тем, что параметров, ассоциированных с той или инойоперацией, относительно немного. С другой стороны, каждой реплике может потребоваться большая процессорная мощность, особенно если операции окажутсясложными.Продвижение против извлеченияДругой вопрос проектирования состоит в том, следует ли обновления продвигать(push) или извлекать (pull).
В протоколах, основанных на продвижении {pushbased protocols), известных также под названием серверных протоколов {serverbased protocols), обновления распространяются по другим репликам, не ожидаяприхода от них запросов на получение обновлений.
Подобный подход часто используется в промежутке между постоянными и инициированными сервером репликами, но может применяться также и для передачи обновлений в клиентскиекэши. Серверные протоколы применяются, когда в репликах в основном следуетподдерживать относительно высокий уровень непротиворечивости. Другими словами, когда реплики должны быть идентичными.Требование высокой степени непротиворечивости связано с тем фактом, чтопостоянные и инициированные сервером реплики, так же как и большие совместно используемые кэши, часто разделяются множеством клиентов, которые осуществляют в основном операции чтения.
Соответственно, соотношение операций чтения к операциям записи для каждой из реплик относительно высоко.В подобных случаях протоколы, основанные на продвижении, эффективнее, в томсмысле, что каждое «продвинутое» обновление будет читаться одним или болеепользователями. Кроме того, протоколы продвижения делают непротиворечивые данные доступными немедленно после запроса.372Глава 6. Непротиворечивость и репликацияВ противоположность им, в подходах, основанных на извлечении (pull-basedapproach), сервер или клиент обращается с запросом к другому серверу, требуяотправить ему все доступные к этому моменту обновления. Методы, основанныена извлечении, называемые клиентскими протоколами (client-based protocols),часто используются при работе с клиентским кэшем. Так, например, стандартнаястратегия, применяемая при работе с кэшами в Web, предполагает предварительную проверку актуальности кэшированных данных.
Когда кэш получает запрос на локально кэшированный элемент данных, он обращается к «родному»web-серверу, проверяя, не был ли этот элемент данных модифицирован послеего кэширования. В том случае, если модификация имела место, модифицированные данные передаются сначала в кэш, а затем — запросившему их клиенту.Если модификации не было, клиенту сразу передаются кэшированные данные.Другими словами, клиент опрашивает сервер в поисках обновлений.Метод извлечения эффективен при относительно небольшом отношении количества операций чтения к количеству операций записи. Такая ситуация характерна для клиентских кэшей, с которыми работает только один клиент (не разделяемых). Однако даже в том случае, когда кэш совместно используется множествомклиентов, подход, основанный на извлечении, может быть весьма эффективен —если кэшируемые элементы данных редко используются совместно.
Основнойнедостаток этой стратегии по сравнению с продвижением состоит в том, что вслучае кэш-промаха (cache miss), то есть когда данные в кэше оказываются неактуальными, время отклика увеличивается.При сравнении подходов, основанных на извлечении и продвижении, можноотметить множество нюансов, часть которых иллюстрирует табл.
6.7. Для простоты ограничимся рассмотрением системы клиент-сервер, состоящей из одногонераспределенного сервера и нескольких клиентских процессов, каждый из которых использует собственный кэш.Т а б л и ц а 6 . 7 . Сравнение протоколов извлечения и продвижения для с и с т е м ыс о д н и м с е р в е р о м и несколькими клиентамиАспектПродвижениеИзвлечениеИнформацияо состоянии на сервереСписок клиентских реплики кэшейНичегоСодержание сообщенийОбновление (и, возможно,сначала запрос)Запрос и обновлениеВремя отклика для клиентаНемедленно (или, в случаезапроса, время полученияобновления)Время получения обновленияВажным для сервера аспектом использования протоколов, основанных напродвижении, является необходимость отслеживать все клиентские кэши. Дажеесли не учитывать тот факт, что, как упоминалось в главе 3, серверы с фиксацией состояния обычно менее устойчивы к сбоям, отслеживание всех клиентскихкэшей может создать серьезную нагрузку на сервер.
Например, при подходе, основанном на продвижении, web-серверу просто придется помнить о каждом издесятков тысяч клиентских кэшей. Каждый раз при обновлении содержимого6.4. Протоколы распределения373web-страницы сервер будет вынужден отыскивать в своем списке те клиентскиекэши, в которых хранится копия этой страницы, и затем передавать обновлениявсем найденным клиентам. Более того, если клиент в поисках свободного местана диске выбросит страницу из своего кэша, он должен будет уведомить об этомсервер, что потребует дополнительного обмена сообщениями.Сообщения, которыми придется обмениваться клиенту и серверу, также различны.
При продвижении единственный тип взаимодействия — обновления, передаваемые сервером клиенту. Если в качестве обновлений фигурируют толькоуведомления о несостоятельности, для получения модифицированных данныхклиент будет нуждаться в дополнительном взаимодействии. При извлеченииклиент должен опрашивать сервер и в случае необходимости получать модифицированные данные.И, наконец, время отклика для клиента также будет различным. Когда серверпродвигает модифицированные данные в кэш клиента, понятно, что время отклика для клиента будет равно нулю.
Если продвигаются только уведомления онесостоятельности, время отклика будет таким же, как и при извлечении (онобудет определяться временем, необходимым для получения с сервера модифицированных данных).Недостатки и достоинства обоих подходов приводят нас к смешанной формераспространения обновлений, основанной на аренде. Аренда (lease) — это обещание сервера определенное время поставлять обновления клиенту. Когда срокаренды истекает, клиент запрашивает у сервера обновления и при необходимости путем извлечения получает от него модифицированные данные. Клиент может также после окончания предыдущего срока аренды запросить у сервера новый, чтобы и далее получать обновления путем продвижения их с сервера.Аренда изначально была предложена в [175], где описан удобный механизмдинамического переключения между стратегиями продвижения и извлечения.В [131] описана гибкая система аренды, позволяющая динамически адаптироватьсрок аренды в соответствии с различными критериями.
Были выделены следующие три типа аренды (отметим, что во всех случаях до истечения срока арендыобновления продвигаются сервером на клиента):4^ аренда, основанная на «возрасте» элемента данных;4 аренда, основанная на том, насколько часто клиент требует обновлениякопии в своем кэше;4 аренда, основанная на объеме дискового пространства, затрачиваемогосервером на сохранение состояния.Аренда, основанная на «возрасте» элемента данных, заканчивается для различных элементов данных в соответствии со временем их последней модификации. Идея, которая лежит в основе этого решения, состоит в том, что если данные в течение длительного времени не модифицируются, значит, они не будутмодифицироваться еще в течение некоторого времени.
Для данных в Web этопредположение кажется разумным. Задавая длительные сроки аренды немодифицируемых данных, мы можем значительно снизить число сообщений обновления по сравнению с одинаковыми сроками аренды для всех элементов данных.374Глава 6. Непротиворечивость и репликацияСледующий критерий — как часто конкретный клиент требует обновлениякопии в своем кэше. При такой аренде сервер устанавливает длительные срокиаренды тем клиентам, кэш которых часто обновляется. С другой стороны, клиент, который только от случая к случаю запрашивает конкретный элемент данных, получает на этот элемент данных краткосрочную аренду. В результате такой стратегии сервер, в сущности, отслеживает только тех клиентов, которыеактивно пользуются его данными и нуждаются в высоком уровне их непротиворечивости.Последний критерий — объем пространства, затрачиваемый сервером на сохранение состояния клиентов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
