背景
近期在重讀“Dynamo: Amazon’s Highly Available Key-value Store”（經典好文，推薦！）。文章4.4 中聊到了Data Version
為了提高可用性，Dynamo同意“更新”操作異步的傳播到其他副本，當出現多個寫事件并發運行時，可能會導致系統中出現多個版本號的對象。
因為我們無法保證分布式系統中的多個結點的物理時鐘是完美同步的，所以通過物理時鐘來確定事件的時序是不靠譜的，但我們能夠通過基于事件的邏輯時鐘來構建部分有序的事件時序集合
Dynamo通過Vector Clock來構建同一對象多個事件的部分有序的時序集合
須要特別說明的是，Vector Clock能解決分布式系統多版本號合并的問題，可是對于確實發生沖突的版本號，它無法合并，而須要用戶自己去做合并
另外，lamport大神寫的“Time Clocks and the Ordering of Events in a Distributed System”能夠覺得是Vector Clock的理論基礎。有興趣同學能夠看看

簡述
Vector Clock是一個向量。向量的每一個分量為（node，count），node即為分布式系統的節點，count為相應節點上的版本號，在處理事件前count會對將該值遞增，當它須要和其他節點進行同步的時候也會把count帶上。
通過比較這些向量的大小。來確定事件發生的順序。

假如一個向量的全部分享量的count值都小于或等于還有一個向量。能夠覺得后者并前者更"新"
否則。存在沖突

演示樣例

1.“用戶A在N1節點上設置x=100” ? ------------ ?節點N1生成向量<(N1,1)>
2.“用戶A在N1節點上設置x=200” ? ------------ ?節點N1生成向量<(N1,2)>
3.“N1將x=200傳播到N2” ----------- ?節點N2生成向量<(N1,2)>
4.“N1將x=200傳播到N3” ----------- ? 節點N3生成向量<(N1,2)>
5.“用戶A在N2節點上設置x=300” ? ------------ ?節點N2生成向量<(N1,2), (N2,1)>
6.“用戶B在N3節點上設置x=400” ??----------- ?節點N3生成向量<(N1,2), (N3,1)>

此時各個節點的向量
N1：?<(N1,2)>
N2：<(N1,2), (N2,1)>
N3：<(N1,2), (N3,1)>

插入一個知識點Quorum NRW模型：
N: 復制的節點數量
R: 成功讀操作的最小節點數
W: 成功寫操作的最小節點數
僅僅需W + R > N。就能夠保證強一致性。

此處我們的N=3
當須要高可寫的系統時，能夠設置W=1 R=3
當須要高可讀的系統時。能夠設置W=3 R=1

如果此處R=3 W=1
7.有個讀x的事件
client其拿到N1,N2,N3上的向量，通過比較可知，N1上的是舊數據，N2/N3版本號存在沖突，此時須要用戶自己去解決沖突

轉載于:https://www.cnblogs.com/bhlsheji/p/5092591.html

總結

以上是生活随笔為你收集整理的Vector Clock理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。