Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Оптимистическая репликация , также известная как ленивая репликация , [1] [2] - это стратегия репликации , в которой репликам разрешено расходиться. [3]

Традиционные пессимистические системы репликации с самого начала пытаются гарантировать, что все реплики идентичны друг другу, как если бы все время существовала только одна копия данных. Оптимистическая репликация устраняет это в пользу конечной согласованности , что означает, что реплики гарантированно сойдутся только тогда, когда система находится в состоянии покоя в течение определенного периода времени. В результате больше не нужно ждать синхронизации всех копий при обновлении данных, что способствует параллелизму и параллелизму . Компромисс состоит в том, что разные реплики могут потребовать явного согласования позже, что может оказаться трудным или даже неразрешимым.

Алгоритмы [ править ]

Оптимистичный алгоритм репликации состоит из пяти элементов:

  1. Представление операции : Пользователи отправляют операции на независимых сайтах.
  2. Распространение : каждый сайт использует операции, о которых он знает, с остальной частью системы.
  3. Планирование : каждый сайт определяет порядок операций, о которых он знает.
  4. Разрешение конфликтов : если есть какие-либо конфликты между операциями, запланированными сайтом, он должен каким-то образом их изменить.
  5. Обязательства : сайты согласовывают окончательный график и результат разрешения конфликта, и операции становятся постоянными.

Существует две стратегии распространения: передача состояния, при которой сайты распространяют представление о текущем состоянии, и передача операций, при которой сайты распространяют операции, которые были выполнены (по сути, список инструкций о том, как достичь нового состояния).

Планирование и разрешение конфликтов могут быть синтаксическими или семантическими. Синтаксические системы полагаются на общую информацию, например, когда и где была отправлена ​​операция. Семантические системы могут использовать информацию, относящуюся к конкретному приложению, для принятия более разумных решений. Обратите внимание, что системы передачи состояния обычно не имеют информации о семантике передаваемых данных, поэтому они должны использовать синтаксическое планирование и разрешение конфликтов.

Примеры [ править ]

Одним из хорошо известных примеров системы, основанной на оптимистической репликации, является система контроля версий CVS или любая другая система контроля версий, которая использует парадигму копирования-изменения-слияния . CVS охватывает каждый из пяти элементов:

  1. Отправка операции: пользователи редактируют локальные версии файлов.
  2. Распространение: пользователи вручную получают обновления с центрального сервера или отправляют изменения, когда пользователь чувствует, что они готовы.
  3. Планирование: операции планируются в порядке их получения центральным сервером.
  4. Разрешение конфликтов: когда пользователь отправляет или извлекает из центрального репозитория, любые конфликты будут помечены, чтобы этот пользователь мог исправить вручную.
  5. Обязательство: как только центральный сервер принимает изменения, которые нажимает пользователь, они фиксируются навсегда.

Особым случаем репликации является синхронизация , когда есть только две реплики. Например, персональные цифровые помощники (КПК) позволяют пользователям редактировать данные либо на КПК, либо на компьютере, а затем объединять эти два набора данных вместе. Однако обратите внимание, что репликация - более широкая проблема, чем синхронизация, поскольку может быть более двух реплик.

Другие примеры включают:

Последствия [ править ]

Приложения, созданные на основе оптимистично реплицированных баз данных, должны быть осторожны, чтобы убедиться, что наблюдаемые отложенные обновления не влияют на корректность приложения.

В качестве простого примера, если приложение содержит способ просмотра некоторой части состояния базы данных и способ его редактирования, то пользователи могут редактировать это состояние, но не видеть его изменения в средстве просмотра. Обеспокоенные тем, что их правка «не сработала», они могут попробовать ее снова, возможно, более одного раза. Если обновления не идемпотентны (например, они увеличивают значение), это может привести к катастрофе. Даже если они идемпотентны, ложные обновления базы данных могут привести к снижению производительности, особенно когда системы баз данных обрабатывают большие нагрузки; это может превратиться в порочный круг.

Тестирование приложений часто проводится в тестовой среде меньшего размера (возможно, только с одним сервером) и менее загруженной, чем «живая» среда. Поведение при репликации такой установки может отличаться от реальной среды, что означает, что задержка репликации вряд ли будет наблюдаться при тестировании, маскируя ошибки, чувствительные к репликации. Разработчики приложений должны быть очень осторожны с предположениями, которые они делают о влиянии обновления базы данных, и должны обязательно моделировать отставание в своих тестовых средах.

Оптимистически реплицируемые базы данных должны быть очень осторожны с предложением таких функций, как ограничения достоверности данных. Если любое данное обновление может быть принято или не принято в зависимости от текущего состояния записи, то два обновления (A и B) могут быть индивидуально законными по отношению к начальному состоянию системы, но одно или несколько обновлений могут быть незаконными. против состояния системы после другого обновления (например, A и B оба допустимы, а AB или BA - незаконны). Если A и B оба инициируются примерно в одно и то же время в базе данных, то A может быть успешно применен на некоторых узлах, а B - на других, но как только A и B «встречаются», и одна попытка выполняется на узле, который уже применив другой, будет обнаружен конфликт. В этом случае система должна решить, какое обновление в конечном итоге «выиграет»,и сделайте так, чтобы все узлы, которые уже применили проигрышное обновление, вернули его. Однако некоторые узлы могут временно раскрыть состояние с отмененным обновлением, и может не быть способа информировать пользователя, инициировавшего обновление, о его сбое, не требуя от них ожидания (потенциально вечно) подтверждения принятия на каждом узле.

Ссылки [ править ]

  1. ^ Ladin, R .; Лисков, Б .; Shrira, L .; Гемават, С. (1992). «Обеспечение высокой доступности с помощью ленивой репликации». ACM-транзакции в компьютерных системах . 10 (4): 360–391. CiteSeerX  10.1.1.586.7749 . DOI : 10.1145 / 138873.138877 . S2CID  2219840 .
  2. ^ Ladin, R .; Лисков, Б .; Шрира, Л. (1990). Ленивая репликация: использование семантики распределенных сервисов . Материалы девятого ежегодного симпозиума ACM по принципам распределенных вычислений . С. 43–57. DOI : 10.1145 / 93385.93399 .
  3. ^ Сайто, Ясуши; Шапиро, Марк (2005). «Оптимистическая репликация». ACM Computing Surveys . 37 (1): 42–81. CiteSeerX 10.1.1.324.3599 . DOI : 10.1145 / 1057977.1057980 . S2CID 1503367 .   
  4. ^ Грей, Дж . ; Helland, P .; О'Нил, П .; Шаша, Д. (1996). Опасности репликации и решение (PDF) . Материалы Международной конференции ACM SIGMOD 1996 г. по управлению данными . С. 173–182. DOI : 10.1145 / 233269.233330 . [ постоянная мертвая ссылка ]
  5. ^ Терри, DB; Таймер, ММ; Петерсен, К .; Демерс, AJ; Spreitzer, MJ; Хаузер, CH (1995). Управление конфликтами обновлений в Bayou, слабо подключенной реплицированной системе хранения . Труды пятнадцатого симпозиума ACM по принципам операционных систем. С. 172–182. DOI : 10.1145 / 224056.224070 .
  6. ^ Kermarrec, AM; Rowstron, A .; Шапиро, М .; Друщель, П. (2001). Подход IceCube к согласованию расходящихся реплик . Материалы двадцатого ежегодного симпозиума ACM по принципам распределенных вычислений . С. 210–218. DOI : 10.1145 / 383962.384020 .

Внешние ссылки [ править ]

  • Сайто, Ясуши; Шапиро, Марк (сентябрь 2003 г.). «Оптимистическая репликация» (PDF) . Microsoft. Цитировать журнал требует |journal=( помощь )