Я почав розглядати підходи до синхронізації даних серед набору однолітків. Ровесники повинні вміти працювати відключеним способом, а потім синхронізуватися разом, щоб об'єднати свої локальні зміни.
Колеги повинні мати можливість об'єднати локальні оновлення з "тристороннім об'єднанням" . Таким чином, при синхронізації однолітки повинні знати, які факти є більш пізніми, але там, де немає чіткого впорядкування, вони повинні мати можливість об'єднати факти на основі спільного кореня.
Коли незалежні однолітки вносять зміни, вони можуть "позначити" час "годинником". Я використовую термін "годинник" і "штамп часу", але я не маю на увазі настінний годинник. Я маю на увазі якусь часткову впорядкованість подій, яка дає зрозуміти причинність. Саме відносини "сталися раніше" між подіями формують спрямований ациклічний графік (DAG).
Схоже, "звичайним" способом побудови цього часткового впорядкування є використання векторного годинника . Однак вони можуть стати дуже великими. Більш недавні розробки, такі як інтервальні годинники, забезпечують більш компактне зберігання часових позначок.
Що мені зовсім не зрозуміло, це те, чому протоколи синхронізації, очевидно, не "просто" зберігають DAG явно. (Або вони?)
Колеги можуть самостійно створювати позначку часу, випадковим чином генеруючи UUID (або іншими способами, такими як <peer-name> + <local-monotonically-increasing-counter>). Упорядкування цієї позначки часу цілком однозначно для цього однолітка.
Коли 2 однолітків синхронізуються один з одним, вони можуть домовитись про нову позначку часу. Знову ж таки, впорядкування цієї позначки часу зрозуміло обом ровесникам.
Зараз існує вимога передавати це, що сталося перед DAG, між одноранговими, але вимоги до зберігання та пропускної здатності цього малі. Часові точки - вершини графіків. Як такі вони мають 1 або 2 вхідні краї (1 для події на клієнті та 2 для синхронізації між клієнтами). Це обмежено і не залежить від кількості однолітків у мережі.
Для використання окремої точки часу вам потрібен графік часових точок, що ведуть до цього. Однак, наскільки я бачу, будь-який одноліток, який здатний знати момент часу (він створив його сам, або створив його з іншим одноранком, або сказав йому інший одноліток при синхронізації з ним) також мав можливість дізнатися про історію, що веде до цього моменту. Я думаю, що для цього, мабуть, є індуктивний доказ.
Зважаючи на те, що зберігання та синхронізація DAG явно видається простою: чи це застосовується на практиці? Якщо ні, то чому переважні векторні годинники?
Примітки
Оглядатись
Я б віддав перевагу рівноправному рішенню над рішенням клієнтського сервера.
Вірогідною кінцевою топологією буде багато клієнтів, що підключаються до набагато меншої групи серверів, які копіюють між собою. Однак було б добре мати загальне рішення, яке б підтримувало цю конкретну топологію, а не рішення, яке вимагає цієї конкретної топології.