Диссертация (1148255), страница 14
Текст из файла (страница 14)
При этом используются следующиеобозначения:1Редкие сообщения, такие как приказ Сервера Клиенту стать Копией, в данной таблице опущены.80– CLN – Клиент (от англ. client)– SRV – Сервер (от англ. server)– BCK – Копия (от англ. backup)– ASK – Запрос (от англ. ask)– CNF – Подтверждение (от англ. confirmation)Например, сообщение CLN_ASK_SRV_RO_LOCK означает запрос Клиента кСерверу на осуществление блокировки на чтение, SRV_ASK_BCK_RO_LOCK – перенаправление этого запроса Сервером к своей Копии, BCK_CNF_SRV_RO_LOCK –подтверждение Копией выполнения операции, и SRV_CNF_CLN_RO_LOCK – разрешение Сервера на осуществление блокировки Клиентом.Остальные цепочки сообщений выглядят аналогичным образом1 , и, чтобыподчеркнуть данную общность, все сообщения в таблице объединены в соответствующие четвёрки, а описание для каждой расшифровывает назначение всейцепочки (назначение отдельных сообщений можно расшифровать, используяинформацию выше).3.3.
Процесс блокировкиРассмотрим реализацию этапов процесса блокировки – на запись (эксклюзивную) и на чтение (неэксклюзивную).3.3.1. Реализация блокировки на запись1. Клиент отправляет сообщение CLN_ASK_SRV_RW_LOCK, в котором указанидентификатор разделяемых данных. Задача, инициировавшая запрос,блокируется до получения ответа.1Следует отметить, что сообщения SRV_CNF_CLN_UPDATE обрабатываются не только инициатором,но всеми Клиентами системы, обновляя локальные значения соответствующих распределённых переменных(см. ниже).812. Сервер, получив запрос на блокировку, проверяет текущее состояниетребуемых данных.
Если ресурс уже заблокирован, то запрос на блокировку ставится в очередь FIFO. Если же блокировка возможна, тосервер помечает данные как блокированные и отправляет сообщениеSRV_ASK_BCK_RW_LOCK.3. Копия, получив запрос на сохранение блокировки, также помечает у себя данные как блокированные и отправляет сообщениеBCK_CNF_SRV_RW_LOCK. Заметим, что здесь попутно проверяется активность как сервера, так и копии, поскольку продолжение сценария требуетобмена сообщениями между ними.4. Сервер, получив подтверждение сохранения блокировки, отправляет сообщение SRV_CNF_CLN_RW_LOCK. Поскольку гарантируется как порядок, таки доставка сообщений, то клиент получит это сообщение только после всехобновлений данных (см.
ниже) и его локальное значение будет актуальным.5. Клиент, получив разрешение на блокировку, возобновляет выполнение задачи, потребовавшей эксклюзивный доступ к разделяемым данным. Теперь клиент может быть уверен, что имеющиеся у него данные актуальныи не будут изменены другими узлами, пока блокировка сохраняется.6. Закончивработусданными,клиентотправляетсообщениеCLN_ASK_SRV_UPDATE, вместе с которым передаётся новое значениеданных. Их целостность обеспечивается системой доставки сообщений.7. Сервер, получив запрос на обновление данных, сохраняет у себя новоезначение и посылает сообщение SRV_ASK_BCK_UPDATE, в котором такжепередаётся новое значение данных.8.
Копия, получив запрос на сохранение данных, также обновляет у себяих текущее значение и отправляет сообщение BCK_CNF_SRV_UPDATE. Одно82временно осуществляется контроль функционирования как Сервера, таки Копии.9. Сервер, получив подтверждение сохранения данных, отправляет сообщение SRV_CNF_CLN_UPDATE с новым значением данных. Это сообщение предназначено для всех узлов. После отправки сообщения пометка о блокировке данных снимается, и сервер проверяет наличие других запросов наблокировку в очереди. Если такие запросы имеются, то начинается их обработка.
Заметим, что в случае запроса блокировки на чтение (см. ниже),совместно с ним будут обработаны и все остальные накопившиеся запросыблокировки на чтение, так как они не мешают друг другу.10. Клиенты, получив команду на обновление данных, устанавливают новоезначение. Поскольку сообщения могут дойти до узлов с разными задержками, синхронность данных в реальном времени не достигается, но благодаря отсутствию потерь и сохранению порядка сообщений, требованиямодели консистентности будет выполнены.3.3.2. Реализация блокировки на чтение1. Клиент отправляет сообщение CLN_ASK_SRV_RO_LOCK, в котором указанидентификатор разделяемых данных. Задача, инициировавшая запрос,блокируется до получения ответа.2.
Сервер, получив запрос на блокировку, проверяет текущее состояние требуемых данных. Если ресурс уже заблокирован на запись, то запрос наблокировку ставится в очередь FIFO. Если же блокировка возможна,то сервер помечает данные как блокированные и отправляет сообщениеSRV_ASK_BCK_RO_LOCK. Заметим, что наличие блокировок на чтение в данном случае не является препятствием.3. Копия, получив запрос на сохранение блокировки, также помечает у себя данные как блокированные и отправляет сообщение83BCK_CNF_SRV_RO_LOCK.
Заметим, что здесь попутно проверяется активность как сервера, так и копии, поскольку продолжение сценария требуетобмена сообщениями между ними.4. Сервер, получив подтверждение сохранения блокировки, отправляет сообщение SRV_CNF_CLN_RO_LOCK. Поскольку гарантируется как порядок, таки доставка сообщений, то клиент получит это сообщение только после всехобновлений данных (см. выше) и его локальное значение будет актуальным.5.
Клиент, получив разрешение на блокировку, возобновляет выполнение задачи, потребовавшей неэксклюзивный доступ к разделяемым данным. Теперь клиент может быть уверен, что имеющиеся у него данные актуальныи не будут изменены другими узлами, пока блокировка сохраняется.6. Закончивработусданными,клиентотправляетсообщениеCLN_ASK_SRV_RELEASE_LOCK. Поскольку данные не изменялись, передавать их значение нет необходимости.7. Сервер, получив запрос на снятие блокировки, посылает сообщениеSRV_ASK_BCK_RELEASE_LOCK.8. Копия, получив запрос на сохранение снятия блокировки, отражает эту операцию в своих системных данных и отправляет сообщениеBCK_CNF_SRV_RELEASE_LOCK. Параллельно происходит контроль функционирования как Сервера, так и Копии.9.
Сервер, получив подтверждение сохранения снятия блокировки, удаляетузел из списка блокирующих. Если список оказался пустым, то пометка облокировке данных снимается, и Сервер проверяет наличие других запросов на блокировку в очереди. Если такие запросы имеются – начинаетсяих обработка.843.4. Отказоустойчивость3.4.1. Термин «сообщение» и атомарностьПрежде всего необходимо уточнить значение термина «сообщение».
В разделах выше мы использовали данный термин в двух значениях – говоря осущности, формируемой примитивами Send и Receive, а также при рассмотрении сущностей, курсирующих на уровне DSM, как, например, представленона рис. 2.4 стр. 65. Временно разделим эти понятия, назвав первое «низкоуровневым сообщением», а второе, соответственно, «высокоуровневым сообщением».На уровне реализации последний тип не всегда совпадает с первым. Весь информационный обмен в МАКС DSM построен вокруг ключевых высокоуровневыхсообщений, являющихся по сути целыми пакетами низкоуровневых сообщенийс данными о произошедших в узле изменениях распределённых переменных.Если информации, которую необходимо передать, немного, и она помещается водно низкоуровневое сообщение, пакет будет состоять из него одного, и значения двух терминов в данном случае будут совпадать. Если же данных много,пакет будет состоять из нескольких низкоуровневых сообщений.
С целью избежать ситуаций, когда одна часть такого пакета доставлена, а другая частьутеряна (например, вследствие сбоя передающего узла), пакеты в МАКС DSMреализованы атомарными. То есть, несмотря на то, что пакет может состоять изнескольких сообщений низкого уровня, все такие сообщения составляют единыйинформационный блок, который интерпретируется на узле-получателе тольков момент получения последнего из составляющих такой блок сообщений. Такойподход используется для абсолютно всех типов высокоуровневых сообщений вМАКС DSM, поэтому в системе как для низкоуровневых так и для высокоуровневых сообщений остаются возможны лишь две ситуации: 1) сообщение доставлено 2) сообщение не доставлено. В связи с этим, нет практической пользы отдальнейшего разделения двух сущностей и в будущем обе сущности мы будемназывать единым термином «сообщение».853.4.2. Действия при выходе узлов из строяВоздействие Клиента на систему в протоколе МАКС DSM в конечномсчёте сводится к отправке ключевых сообщений CLN_ASK_SRV_UPDATE илиCLN_ASK_SRV_RELEASE_LOCK после завершения Клиентом работы с распределёнными данными.
Если Клиент запросил блокировку и вышел из строя, тоСервер, обнаружив наличие блокировки в течение времени, превышающегозаданное1 , принудительно её снимает. При этом, в случае блокировки на запись, она передаётся следующему в очереди узлу. В случае же блокировки начтение (или отсутствии узлов в очереди), Сервер посылает Копии сообщениеSRV_ASK_BCK_RELEASE_LOCK и считает блокировку исчезнувшим узлом снятой.Узел помечается как «пропавший», и если от него всё-таки придёт сообщение CLN_ASK_SRV_UPDATE или CLN_ASK_SRV_RELEASE_LOCK, то оно игнорируется. Клиент может продолжить работу с сообщений CLN_ASK_SRV_RW_LOCK илиCLN_ASK_SRV_RO_LOCK.Функционирование Копии проявляется в системе отправкой подтверждающих сообщений BCK_CNF_* в ответ на сообщения сервера SRV_ASK_BCK_*.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
