Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 95
Текст из файла (страница 95)
(И снова, размер этогонабора может быть слишком велик для существующих требований по производительности. Альтернативные решения будут изложены ниже.) Сервер удостоверяется, что указанные операции записи выполнялись первыми и в правильномпорядке. После выполнения новой операции идентификатор записи этой операции добавляется к набору записи. Отметим, что актуализация набора записи текущего сервера при помощи набора записи клиента может существенно увеличить время отклика сервера.Непротиворечивость чтения собственных записей также требует, чтобы сервер, на котором выполняются операции чтения, имел доступ ко всем операциямзаписи из набора записи клиента. Операции записи можно просто извлекать сдругих серверов перед выполнением операции чтения, даже если это грозитобернуться проблемами с временем отклика.
С другой стороны, клиентское программное обеспечение может само найти сервер, на котором операции записи,указанные в наборе записи клиента, уже выполнены.И, наконец, непротиворечивость записи за чтением может быть реализованаследующим образом. Сначала выбранный сервер актуализируется с помощьюопераций записи, входящих в набор чтения клиента, а затем в набор записи добавляются идентификатор операции записи и идентификаторы из набора чтения(таким образом, учитывается только что выполненная операция записи).Повышение производительностиЛегко заметить, что наборы чтения и записи, ассоциированные с каждым клиентом, могут стать чересчур большими. Чтобы сохранить управляемость этих наборов, операции чтения и записи клиента могут группироваться в сеансы. Сеансыобычно ассоциируются с приложениями: они открываются при запуске приложения и закрываются по окончании работы с ним.
Однако сеансы также могут ассоциироваться и с временно запускаемыми приложениями, такими как пользовательский агент для электронной почты. В любом случае, когда клиент закрываетсеанс, наборы очищаются. Разумеется, если клиент откроет сеанс и никогда егоне закроет, ассоциированные с ним наборы чтения и записи могут стать оченьбольшими.Основная проблема примитивной реализации вытекает из способа представления наборов чтения и записи. Каждый из наборов включает в себя множество6.4. Протоколы распределения365идентификаторов операций записи. Когда клиент передает серверу запрос на запись или чтение, серверу передается и набор идентификаторов — для проверкитого факта, что все операции записи соответствуют обрабатываемому на серверезапросу.Эту информацию удобнее представлять в виде векторных отметок времениследующим образом.
Сначала когда сервер принимает требование на проведениеновой операции записи W, он описанным выше способом присваивает этой операции глобально уникальный идентификатор WID вместе с отметкой времениts(WID), Следующая операция записи на этом сервере получает отметку временис большим значением. Каждый сервер 5, поддерживает векторную отметку времени RCVD(i), где RCVD(i)[j] соответствует отметке времени последней операции записи, инициированной на сервере 5,, которая была получена (и обработана) сервером Sj.Когда клиент посылает запрос на выполнение операции записи или чтения наопределенный сервер, сервер возвращает свою текущую отметку времени вместес результатом этой операции. Наборы чтения и записи представляются последовательными векторными отметками времени.
Для любого такого набора Л мысоздаем векторную отметку времени VT(A) с набором УГ(Л)[2], равным отметкевремени, максимальной среди всех операций Л, инициированных на сервере 5„что приводит к эффективному представлению этих наборов.Объединение двух наборов идентификаторов, Л и Б, обозначается в виде векторной отметки времени VT(A +Л), где VT[A -^ B)[i] равно max(VT(A)[i], VT(B)[i]).К тому же, чтобы выяснить, содержится ли набор идентификаторов А в другомнаборе В, нам нужно проверить только, выполняется ли для каждого индекса iусловие VT(A)[i]..,VT(B)[i].Когда сервер возвращает клиенту свою текущую отметку времени, клиентприводит в соответствие с ней векторную отметку времени своего собственногонабора чтения или записи (в зависимости от выполняемой операции).
Рассмотрим вариант с непротиворечивостью монотонного чтения, при которой клиентус сервера 5 возвращается векторная отметка времени. Если векторная отметканабора чтения клиента — VT(Rset), то для каждого индекса j значение VT(Rset)[j]равно max{VT(Rset)[j], RCVD(i)[j]}. Набор чтения клиента отражает последнююизвестную ему операцию записи. Соответствующая векторная отметка временибудет послана (возможно, на другой сервер) в ходе следующей операции чтенияклиента.6.4.
Протоколы распределенияДо сих пор мы рассуждали лишь о тех или иных моделях непротиворечивости,стараясь поменьше обращать внимания на их реализацию. В этом разделе мы обсудим различные способы распространения, точнее способы распределения адресованных репликам обновлений независимо от поддерживаемой ими моделинепротиворечивости. Протоколы для конкретных моделей непротиворечивостимы рассмотрим в следующем разделе.366Глава 6. Непротиворечивость и репликация6 . 4 .
1 . Размещение репликОсновную проблему проектирования распределенных хранилищ данных, которую мы должны решить, — это когда, где и кому размещать копии хранилища (см.также [233]). Различают три различных типа КОПРШ, логически организованныхтак, как показано на рис. 6.18.— • Репликация, инициируемая сервером- - - • Репликация, инициируемая клиентомРис. 6.18.
Логическая организация различных типов копий хранилищ данныхв виде трех концентрических колецПостоянные репликиПостоянные реплики можно рассматривать как исходный набор реплик, образующих распределенное хранилище данных. Во многих случаях число постоянных реплик невелико. Рассмотрим, например, web-сайт. Распределение web-сайтовобычно происходит в одном из двух вариантов. В первом варианте распределенияфайлы, которые составляют сайт, реплицируются на ограниченном числе серверов одной локальной сети. Когда приходит запрос, он передается одному из серверов, например, с использованием стратегии обхода кольца [96].Второй тип распределения web-сайтов — это создание зеркал (mirroring).В этом случае web-сайт копируется на ограниченное количество разбросанныхпо всему Интернету серверов, называемых зеркальными сайтами (mirror sites),или просто зеркалами.
В большинстве случаев клиенты просто выбирают одноиз зеркал из предложенного им списка. Зеркальные web-сайты обычно основанына технологии кластерных web-сайтов, поддерживающих одну или несколькореплик с возможностью в той или иной степени их статического конфигурирования.Подобная же статическая организация применяется и для создания распределенных баз данных [337]. Базы данных могут быть реплицированы и распределены по нескольким серверам, образующим вместе кластер рабочих станций (Cluster Of Workstations, COW).
О таких кластерах часто говорят как об архитектуребез разделения (shared-nothing architecture), подчеркивая, что ни диски, ни оперативная память не используются процессорами совместно. С другой стороны, ба-6.4. Протоколы распределения367зы данных могут распределяться и возможно реплицироваться по множествугеографически разбросанных мест. Такая архитектура нередко применяется припостроении федеральных баз данных [416].Реплики, инициируемые серверомв противоположность постоянным репликам, реплики, инициируемые сервером,являются копиями хранилища данных, которые создаются для повышения производительности и создание которых инициируется хранилищем данных (еговладельцем).
Рассмотрим, например, web-сервер, находящийся в Нью-Йорке.Обычно этот сервер в состоянии достаточно быстро обрабатывать входящие запросы, но может случиться так, что внезапно в течение нескольких дней из неизвестного удаленного от сервера места портдет поток запросов. (Такой поток, как показывает короткая история Web, может быть вызван множеством причин.) В этомслучае может оказаться разумным создать в регионах несколько временных реплик, призванных работать с приходящими запросами. Эти реплики известны также [190] под названием выдвинутых кэшей {push caches).Совсем недавно проблема динамического размещения реплик была подхвачена службами web-хостинга.