Как определить выигрыш последней записи на одновременных часах Vector?

Question

Я хотел бы отслеживать только последние данные, а также использовать помощь Vector Clock в решении проблем, чтобы я мог легко отбросить данные с помощью правила LWW (последняя победа при записи) Скажем, у нас есть 3 узла:

- Node1
- Node2
- Node3

Затем мы будем использовать векторные часы, чтобы отслеживать причинность и параллелизм каждого события / изменения. Векторные часы мы представляем изначально с

{Node1:0, Node2:0, Node3:0}.

Например, Node1 получает 5 локальных изменений, это будет означать, что мы увеличиваем его тактовую частоту на 5 приращений, что приведет к

{Node1: 5, Node2:0, Node3:0}.

Это было бы нормально нормально, верно?

Тогда что, если в то же время Node2 обновляет свой локальный, а также увеличивает свои часы в результате

{Node1:0, Node2:1, Node3:0}.

В какой-то момент Node1 отправляет событие Node3, передавая обновления и совмещая свой векторный блок. Итак, Node3, который имеет VC {Node1:0, Node2:0, Node3:0} будет легко просто объединить данные и часы, так как пока нет никаких изменений.

Проблема, о которой я думаю, заключается в том, что произойдет, если Node2 отправит событие для обновления в Node3, передав свой собственный VC и обновления. Что будет с данными и часами. Как я применяю Last Write, выигрывает здесь, когда первая, которая записывается в Node3, которая была из Node1, будет в основном отображаться как более поздняя запись, поскольку она имеет большее значение VC на своих собственных часах. Часы Node3 перед слиянием: {Node1: 5, Node2: 0 , Node3: 1}Сообщение Node2, полученное Node3: {Node1:0, Node2:1, Node3:0}

Как мне обработать данные разрешения на одновременных VC?

Answer 1

Это хороший вопрос. Вы столкнулись с этой проблемой, потому что вы используете счетчики в своих векторных часах, и вы не синхронизируете счетчики между узлами. У вас есть несколько вариантов:

1. Отправить все записи через один основной сервер. Основной сервер может применить общий порядок ко всем записям и затем отправить их на отдельные узлы, которые будут сохранены. Было бы полезно иметь некоторое представление о вашей системе. Например, почему существуют три независимых узла? Существуют ли они для обеспечения репликации и доступности? Если это так, этот основной серверный подход будет работать хорошо.
2. Синхронизируйте время вашего сервера, как описано в статье Google Spanner. Затем вместо монотонно увеличивающегося счетчика для каждого узла в векторных часах вы можете использовать временную метку, основанную на времени сервера. Опять же, было бы полезно иметь представление о вашей системе. Если ваша система состоит только из пользователей, отправляющих записи, то вам, возможно, удастся обойтись без синхронизации времени вашего сервера с использованием NTP без нарушения инварианта LWW.