Э. Таненбаум, М. ван Стеен - Распределённые системы (принципы и парадигмы) (1162619), страница 85
Текст из файла (страница 85)
Обзор329Однако во многих случаях можно использовать простые модели, которые несложно реализовать. Один из конкретных классов подобных моделей — клиентские модели непротиворечивости, которые ограничиваются непротиворечивостьюс точки зрения одного (возможно, мобильного) клиента. Клиентские модели непротиворечивости рассматриваются в отдельном разделе.Непротиворечивость — это еще не все. Мы должны также обсудить, как этанепротиворечивость реализуется на практике.
В поддержании непротиворечивости реплик играют роль два более или менее независимых аспекта. Первый изних — это реальное распространение обновлений. Сюда входят вопросы размещения реплик и того, как по ним расходятся обновления. Мы опишем и сравнимнесколько протоколов распространения.Второй аспект касается поддержания непротиворечивости реплик. В большинстве слз^аев приложениям необходим жесткий вариант непротиворечивости.Говоря неформально, это означает, что обновления должны расходиться по репликам более или менее быстро. Существует несколько альтернативных реализаций строгой непротиворечивости, которые будут рассмотрены в отдельномразделе.
Кроме того, внимание уделяется протоколам кэширования, представляющими собой особую форму протоколов поддержания непротиворечивости.Мы закончим эту главу двумя примерами приложений, в которых активноиспользуются непротиворечивость и репликация. Первый пример относится кобласти параллельного программирования и упомиршется также при обсуждении распределенных систем на базе объектов в главе 9. Второй пример охватывает вопросы причинной непротиворечивости и того, что называется медленнойрепликацией.6 . 1 . ОбзорЭтот раздел мы начнем с разговора об основных доводах в пользу репликацииданных.
Специальное внимание будет уделено реплицируемым объектам, к которым в современных распределенных системах проявляется все больший интерес.И наконец, мы обсудим репликацию, как метод улучшения масштабируемости,и расскажем, почему рассуждения о непротиворечивости столь важны для нас.6.1.1. Доводы в пользу репликациив пользу репликации есть два основных довода ~ надежность и производительность.
Во-первых, данные реплицируются для повышения надежности системы.Если файловая система реплицирована, она может продолжать свою работу после сбоя в одной из реплик, просто переключившись на другую. Кроме того, поддерживая несколько копий, легче противостоять сбоям данных. Так, представимсебе, что существует три копии некоего файла и операции чтения и записи производятся со всеми тремя. Мы можем защитить себя от единичной неудачной операции записи, считая правильным значение, которое выдают как минимум двекопии.330Глава 6.
Непротиворечивость и репликацияДругой довод в пользу репликации данных — производительность. Репликация повышает производительность, когда распределенную систему приходитсямасштабировать на множество машин и географических зон. Масштабированиена множество машин имеет место, например, когда возрастает число процессов,требующих доступа к данным, управляемым одним сервером.
В этом случаепроизводительность можно повысить путем репликации сервера с последующимразделением общего объема работы между сервером и репликами. Мы уже приводили этот пример в главе 1, когда кратко рассматривали кластеры реплицированных web-серверов.При масштабировании на увеличившуюся географическую зону мы также нуждаемся в репликации. Основная идея состоит в помещении копии данных поблизости от использующего ее процесса, что ведет к сокращению времени доступа.В результате наблюдаемая производительность процесса возрастает. Этот пример иллюстрирует также и то, что выигрыш в производительности, получаемыйблагодаря репликации, оценить не просто.
Хотя в клиентском процессе можетнаблюдаться рост производительности, возможна ситуация, в которой для своевременного обновления всех реплик потребуется увеличение пропускной способности сети. Мы вернемся к этой теме при обсуждении протоколов распространения.Если репликация помогает повысить надежность и производительность, чтонам может помешать? К сожалению, это цена, которую нам придется заплатитьза репликацию данных. Проблема репликации в том, что наличие множества копий может создать проблемы с непротиворечивостью данных.
Каждый раз приизменении копии она начинает отличаться от всех прочих. Соответственно, длясохранения непротиворечивости эти изменения должны быть перенесены и наостальные копии. То, как и когда следует переносить эти изменения, и определяет цену репликации.Чтобы разобраться в проблеме, рассмотрим постоянно растущее время доступа к web-страницам. Если не предпринимать никаких специальных мер, загрузкастраницы с удаленного web-сервера может занимать до нескольких секунд.
Дляповышения производительности web-браузеры часто локально сохраняют копиизагруженных ранее web-страниц (то есть кэшируют web-страницы). Если пользователь снова запросит подобную страницу, браузер автоматически вернет емулокальную копию. Скорость доступа, с точки зрения пользователя, будет потрясающая. Однако, если пользователь всегда хочет иметь последнюю версию страницы, его может постичь разочарование.
Проблема состоит в том, что если в промежутке между обращениями страница будет модифицирована, модификации нераспространяться на копии в кэше, что сделает эти копии устаревшими.Одно из решений проблемы возвращения пользователю актуальных копийсостоит в том, чтобы запретить браузеру хранить локальные копии, а задачу обновления полностью возложить на сервер. Однако это решение может привести к увеличению времени доступа, ведь тогда у пользователя не будет реплик.Другое решение — позволить web-серверу объявлять кэшированные копии устаревшими или обновлять их, но тогда серверу придется проверять все кэшированные копии и рассылать им сообщения.
Это, в свою очередь, может привести6.1. Обзор331к снижению общей производительности сервера. Ниже мы еще вернемся к конфликту «производительность против масштабируемости».6.1.2. Репликация объектовЧтобы лучше понять роль распределенных систем в том, что касается управленияданными (совместно используемыми), полезно рассматривать не отдельные данные, а объекты. Достоинство объектов состоит в том, что они инкапсулируютданные и операции над ними. Это облегчает нам разделение операций, которыезависят от данных, и операций, которые от данных не зависят. Последний типопераций обычно встречается в распределенных системах общего назначения, например тех, которые реализуются посредством многих описанных в этой книгесистем промежуточного уровня.Рассмотрим распределенный удаленный объект, совместно используемый многими клиентами (рис.
6.1). До того как мы начнем думать о репликации удаленного объекта на несколько машин, мы должны решить проблему защиты объектаот одновременного доступа нескольких клиентов. У этой проблемы существуютдва основных решения [75].Машина клиентаМашина сервераМашина клиентаСервер— ^,£^ппп^^—Iщ^шщ—^1г1—1J—1П^^АСкелетон>к t к^Г1—11—1Г—ПОС сервераV)J^чJСетьРис. 6 . 1 . Организация распределенного удаленного объекта,совместно используемого двумя клиентамиПервое из решений состоит в том, что одновременные вызовы обрабатываетсам объект. В качестве примера укажем, что объект Java может быть сконструирован в виде монитора путем объявления его методов си}Щ)онизированными. Предположим, что два клиента одновременно вызывают метод одного и того же объекта.
Это приведет к появлению двух параллельных потоков выполнения на томсервере, на котором находится этот объект. В Java, если методы объекта синхронизированы, выполняться будет только один из потоков выполнения, второй жеокажется заблокированным до дальнейших уведомлений.
Могут быть созданыразличные уровни параллельного выполнения, но основным моментом будет то,что средства обработки параллельных обращений реализует сам объект. Этотпринцип иллюстрирует рис. 6.2, а.332Глава 6. Непротиворечивость и репликацияМашина сервераМашина сервераСерверпппМеханизмвзаимного исключенияЖЖАСкелетонПараллельныеобращенияiAAAАдаптерОС^МеханизмвзаимногоисключенияАдаптерAAAПараллельныеобращенияВходящие запросыВходящие запросыабРис.
6.2. Удаленный объект, способный самостоятельно обрабатывать параллельныеобращения (а). Удаленный обьект, которому для обработки параллельныхобращений необходим адаптер объекта (б)Второе решение состоит в том, что объект вообще никак не защищается от параллельных обращений, вместо него ответственность за работу с параллельнымиобращениями несет сервер, на котором расположен объект. В частности, используя соответствующий адаптер объектов, он может обеспечить, чтобы параллельные обращения не повреждали объект. Например, адаптер объектов, использующий для каждого объекта один поток выполнения, может сериализовать весьдоступ к каждому из объектов, которыми он управляет (рис.
6.2, б).Репликация удаленных, совместно используемых объектов без специальныхприемов обработки параллельных обращений может привести к проблемам с непротиворечивостью. Эти проблемы связаны с тем, что для параллельных обращений в правильной очередности реплики нуждаются в дополнительной синхронизации. Примером такой синхронизации может быть реплицируемая база данных банковских счетов, описанная в разделе 5.2. И вновь у нас есть два основныхспособа решения проблемы.Первый подход основан на осведомленности объекта о том, что он был реплицирован. В этом случае сам объект отвечает за непротиворечивость своей репликив условиях параллельных обращений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
