Я начал смотреть на подходы к синхронизации данных среди множества пиров. Узлы должны иметь возможность работать автономно и затем синхронизироваться друг с другом, чтобы объединить свои локальные изменения.
Узлы должны иметь возможность объединять локальные обновления с «трехсторонним объединением» . Таким образом, при синхронизации узлы должны знать, какие факты являются более свежими, но там, где нет строгого упорядочения, они должны иметь возможность объединять факты, основанные на общем корне.
Когда независимые узлы вносят изменения, они могут «помечать» их «часами». Я использую термины «часы» и «отметка времени», но я не имею в виду настенные часы. Я имею в виду некоторый частичный порядок событий, который проясняет причинность. Это отношение «произошло раньше» между событиями, которое формирует направленный ациклический граф (DAG).
Кажется, что «обычный» способ сделать это частичное упорядочение - использовать векторные часы . Однако они могут стать очень большими. Более поздние разработки, такие как интервальное дерево, обеспечивают более компактное хранение меток времени.
Я не совсем понимаю, почему протоколы синхронизации явно «просто» не хранят DAG явно. (Или они?)
Одноранговые узлы могут независимо создавать метку времени путем случайного генерирования UUID (или другими способами, такими как <peer-name> + <local-monotonically-increasing-counter>). Порядок этой отметки времени совершенно ясен для этого пира.
Когда 2 узла синхронизируются друг с другом, они могут договориться о новой отметке времени. Опять же, порядок этой метки времени понятен обоим пирам.
В настоящее время существует требование для передачи произошедшего до DAG между узлами, но требования к хранилищу и пропускной способности этого невелики. Точки времени - вершины графа. Таким образом, они имеют 1 или 2 входящих фронта (1 для события на клиенте и 2 для синхронизации между клиентами). Это ограничено и не зависит от количества пиров в сети.
Чтобы использовать отдельную временную точку, вам нужен график временных точек, которые приводят к этому. Однако, насколько я могу видеть, любой узел, который может знать момент времени (он сгенерировал его сам, или сгенерировал его с другим узлом, или ему сказали об этом другой узел при синхронизации с ним), также имел возможность узнать об истории, ведущей к тому времени. Я думаю, что, вероятно, есть индуктивное доказательство этого.
Учитывая, что хранение и синхронизация DAG явно кажутся простыми: используется ли это на практике? Если нет, то почему предпочитают векторные часы?
Примечания
Пиринговый
Я бы предпочел одноранговое решение, а не клиент-серверное решение.
Вероятной конечной топологией будет множество клиентов, подключающихся к гораздо меньшей группе серверов, которые реплицируются между собой. Однако было бы неплохо иметь общее решение, которое поддерживает эту конкретную топологию, а не решение, которое требует этой конкретной топологии.