Оптимистическая репликация , также известная как ленивая репликация , [1] [2] представляет собой стратегию репликации , при которой репликам разрешено расходиться. [3]
Традиционные пессимистические системы репликации пытаются гарантировать с самого начала, что все реплики идентичны друг другу, как если бы все время была только одна копия данных. Оптимистическая репликация устраняет это в пользу окончательной согласованности , то есть реплики гарантированно сходятся только тогда, когда система находится в состоянии покоя в течение определенного периода времени. В результате больше нет необходимости ждать синхронизации всех копий при обновлении данных, что способствует параллелизму и конкурентности . Компромисс заключается в том, что различные реплики могут потребовать явного согласования позже, что может затем оказаться сложным или даже неразрешимым.
Алгоритм оптимистичной репликации состоит из пяти элементов:
Существует две стратегии распространения: передача состояния, когда сайты распространяют представление текущего состояния, и передача операций, когда сайты распространяют выполненные операции (по сути, список инструкций о том, как достичь нового состояния).
Планирование и разрешение конфликтов могут быть синтаксическими или семантическими. Синтаксические системы опираются на общую информацию, например, когда или где была отправлена операция. Семантические системы могут использовать информацию, специфичную для приложения, для принятия более разумных решений. Обратите внимание, что системы передачи состояний обычно не имеют информации о семантике передаваемых данных, поэтому им приходится использовать синтаксическое планирование и разрешение конфликтов.
Одним из известных примеров системы, основанной на оптимистической репликации, является система контроля версий CVS или любая другая система контроля версий, которая использует парадигму копирования-изменения-слияния. CVS охватывает каждый из пяти элементов:
Частным случаем репликации является синхронизация , когда есть только две реплики. Например, персональные цифровые помощники (КПК) позволяют пользователям редактировать данные либо на КПК, либо на компьютере, а затем объединять эти два набора данных вместе. Однако следует отметить, что репликация — более широкая проблема, чем синхронизация, поскольку реплик может быть больше двух.
Другие примеры включают в себя:
Приложения, созданные на основе оптимистичных реплицированных баз данных, должны быть осторожны и гарантировать, что наблюдаемые отложенные обновления не нарушат корректность работы приложения.
В качестве простого примера, если приложение содержит способ просмотра некоторой части состояния базы данных и способ ее редактирования, то пользователи могут редактировать это состояние, но затем не видеть его изменения в средстве просмотра. Встревоженные тем, что их редактирование «не сработало», они могут попробовать сделать это снова, потенциально больше одного раза. Если обновления не идемпотентны (например, они увеличивают значение), это может привести к катастрофе. Даже если они идемпотентны, ложные обновления базы данных могут привести к узким местам производительности, особенно когда системы баз данных обрабатывают большие нагрузки; это может стать порочным кругом.
Тестирование приложений часто выполняется в тестовой среде, меньшей по размеру (возможно, всего один сервер) и менее загруженной, чем «живая» среда. Поведение репликации такой установки может отличаться от реальной среды способами, которые означают, что задержка репликации вряд ли будет наблюдаться при тестировании, маскируя ошибки, чувствительные к репликации. Разработчики приложений должны быть очень осторожны в своих предположениях относительно эффекта обновления базы данных и должны быть уверены, что моделируют задержку в своих тестовых средах.
Оптимистично реплицированные базы данных должны быть очень осторожны в отношении предоставления таких функций, как ограничения достоверности данных. Если любое данное обновление может быть принято или не принято на основе текущего состояния записи, то два обновления (A и B) могут быть индивидуально законными относительно начального состояния системы, но одно или несколько обновлений могут быть незаконными относительно состояния системы после другого обновления (например, A и B оба законны, но AB или BA незаконны). Если A и B оба инициированы примерно в одно и то же время в базе данных, то A может быть успешно применено на некоторых узлах, а B — на других, но как только A и B «встретятся» и одно будет предпринято на узле, который уже применил другое, будет обнаружен конфликт. В этом случае система должна решить, какое обновление в конечном итоге «выиграет», и организовать отмену его для всех узлов, которые уже применили проигравшее обновление. Однако некоторые узлы могут временно раскрывать состояние с отмененным обновлением, и может не быть способа сообщить пользователю, инициировавшем обновление, о его сбое, не требуя от него ожидания (потенциально вечно) подтверждения принятия на каждом узле.