Чтобы взять самый простой пример:
- Начните с пустой базы данных.
- Добавьте документ
- Добавьте документ проекта с функцией проверки, которая отклоняет все
- Скопируйте эту базу данных.
Чтобы задать конкретный вопрос для начала, ответ, который, я надеюсь, можно получить очень быстро, указав мне правильный URL-адрес:результат этой репликации определяется по какому-то правилу, например, что документы всегда реплицируются в том порядке, в котором они были сохранены, или успешная репликация первого документа зависит от того, получился ли проектный документ первым в месте назначения?В быстром эксперименте, который я сделал, оба документа прошли успешную проверку, но я пытаюсь выяснить, определен ли этот результат в спецификации где-то или он зависит от реализации.
Чтобы задать дополнительный вопрос, который более ручени может не иметь единого ответа, что еще может произойти и какие решения появились для решения этих проблем?Очевидно, что разные серверы могут одновременно (и я нерешительно использую это слово) иметь разные версии функции проверки.Я предполагаю, что валидаторы могут быть обратно совместимы, когда каждая новая версия добавляет регистр к оператору switch, который ищет, скажем, атрибут schema_version документа.Затем, если документ версии 2 поступит на сервер, на котором валидатор версии 3 является привратником, он будет допущен. Если документ версии 3 прибудет на валидатор версии 2, это будет немного сложнее, это, вероятно, зависит от того, насколько строгостьили снисходительность является подходящим значением по умолчанию для приложения.Но может ли что-то из этого даже произойти, или правила репликации гарантируют, что даже если серверы работают вверх и вниз, обновления и удаления выполняются повсеместно, а репликационные соединения являются прерывистыми и косвенными, что документ никогда не будет доставленна указанном сервере до его соответствующей функции проверки, и что функция проверки никогда не поступит слишком поздно для обработки одного из документов, которые она должна была проверить?
Я вполне мог бы слишком усложнить это или упустить какой-то дзенпроницательность, но болезненный опыт научил меня, что я не достаточно умен, чтобы предсказать, в какие состояния параллельные системы могут попасть.
EDIT:
Как говорит Марчелло в комментарии, обновления на отдельных серверах имеют порядковые номера, и репликация применяет обновления в порядке порядкового номера.У меня было смутное представление о том, что это так, но я все еще не совсем уверен в деталях.Я пытаюсь найти простейшую возможную модель, которая даст мне представление о том, что может и не может произойти в сложной системе CouchDB.
Предположим, я взял состояние сервера A, который был запущен пустым, и в него было сделано три записи документа.Таким образом, его состояние может быть представлено в виде следующей строки: A1, A2, A3
Предположим, что сервер B также имеет три записи: B1,B2,B3
Мы копируем A в B, поэтому состояние Bсейчас: B1,B2,B3,A1,A2,A3.Хотя предположительно для обновлений А при вводе В был принят порядковый номер, поэтому состояние теперь: B1, B2, B3, B4(A1), B5(A2), B6(A3).
Если я правильно понимаю, репликатор также делает запись того факта, что все до А3 имеетбыла реплицирована в B, и она хранит эту запись как часть внутреннего состояния B, но мне интересно, не является ли это деталью реализации, которую можно игнорировать в простой модели.
Если вы работаете с этими наборамиправил, обновления A и B будут оставаться в порядке на любом сервере, на который они были реплицированы.Возможно, единственный способ, которым они могут выйти из строя, - это если вы сделали что-то вроде репликации A на B, удаления A1 на A и A2 на B, репликации от A до C, затем репликации от B до C, оставив состояние на C: A2, A3, B1, B2, B3, B4(A1).
Это вообще имеет смысл?Возможно, строки не являются правильным способом визуализации, может быть, лучше подумать, я не знаю, о куче очередей (серверов) в аэропорту, сотрудников аэропорта (репликаторов), перемещающих людей из очереди в очередь согласно определеннымправила, и поставьте себя в голову кому-то, пытающемуся пропустить очередь, то есть каким-то образом попасть в очередь перед тем, кто опередит их в их текущей очереди.Это имеет преимущество персонализации модели, но мы, вероятно, не хотим копировать людей в аэропортах.
Или, может быть, есть какой-то способ объяснить это как игру типа Towers of Hanoi, хотя с очередями FIFO вместо стеков LIFO.
Это модель, которую я надеюсь найти - абсолютно точная в том, что касается поведения, все несущественные детали реализации отбрасываются, а использование любой метафоры или изображений упрощает интуитивное понимание.