時間戳和向量圖

時間戳策略

摘自《大數據挑戰與NoSQL數據庫技術》 2.4.3 時間戳策略

在關係數據庫中有普遍的應用，該策略主要用於關係數據庫日誌系統中記錄事務操做，以及數據恢復時的Undo/Redo等操做。在並行系統中，時間戳策略有更加普遍的應用。從較高的層次來講，時間戳策略可用於SNA架構或並行架構系統中的時間、數據的同步。

        在並行數據存儲系統或並行數據庫中，因爲數據時分散存儲在不一樣的節點上的，那麼對於不一樣節點上的數據如何區分它們的版本信息將成爲比較繁瑣的事情，該問題將涉及到不一樣節點之間的同步問題。若使用時間戳策略將可以很好地緩解這一境況，例如，咱們能夠爲每一份或一組數據附加一個時間戳標記。在進行數據版本比較或數據同步的時候只須要比較其時間戳就能夠區分他們之間的版本。可是分佈式系統中不一樣節點之間的物理時鐘可能會有誤差，這樣就可能致使交完更新的數據其時間戳卻比較晚。所以咱們設置一個全局時鐘來進行時間同步。當一份數據更新以後，該數據所在節點向全局時鐘請求一個時間戳。那麼，此時新的問題將出現：1）該全局時鐘同步開銷過大，影響系統效率；2）該全局時鐘出現宕機，整個系統將沒法工做。所以，該系統時鐘將成爲系統效率和可用性的瓶頸。

        使用時間戳的策略將可以很好地解決這一問題。時間戳策略不依賴於任何單個的機器，也不依賴於物理是綜合可以。該時間戳爲邏輯上的時鐘，而且經過時間戳版本的更新能夠在系統中生成一個全局有序的邏輯關係。下面咱們將簡單介紹該策略的核心思想。

1  時間戳

        時間戳最先用於分佈式系統中進程之間的控制，用於肯定分佈式系統中事件的前後關係，可用於協調分佈式系統中的資源控制。

咱們假設發送或接受消息是進程中的一個事件，下面咱們來定義分佈式系統事件集中的前後關係，用「→」符號來表示，例如：若事件a發生在事件b之間，那麼有a→b。

該關係須要知足下列三個條件：

1) 若是事件a和事件b是同一個進程中的事件，而且a在b以前發生，那麼有a→b；

2) 若是事件a是某消息發送方進程中的事件，事件b是該消息接收方進程中接收該消息的事件，那麼有a→b；

3) 對於事件a、事件b和事件c,若是有a→b和b→c，那麼a→c。

若是兩個不一樣的事件a和事件b，既不能得出a→b也不能得出b→a，那麼有事件a和事件b同時發生。

如圖1所示，下面咱們經過該圖說明系統中可能存在的事件前後關係。

圖1：分佈式系統多進程通訊

 

在圖1中，縱向表明事件軸，虛線表示進程之間的消息通訊。在該模型中，若是存在着一個從a到b的時間或消息的前後關係，那麼有a→b。

例1：在同一進程P中，事件p₂發生在事件p₁以後，所以有p₁→p₂。

例2：對於事件q₁和時間p₃，因爲存在從q₁到p₂的消息傳遞，所以有q₁→p₂，同時在同一進程P中，咱們知道p₂→p₃，所以根據該模型，有q₁→p₃。

例3：對於事件p₃和事件q₃，在邏輯上，咱們不能肯定p₃是否在q₃以前發生（只能得出p₃在q₁以前發生），也不能肯定q₃是否在p₃以前發生（只能得出）q₃在p₁以前發生。儘管在物理時間上，q₃要先於p₃發生，可是咱們不能肯定兩事件在該模型下的邏輯關係，所以咱們說p₃和q₃同時發生。

2 邏輯時鐘

        如今咱們將時鐘引入到系統中。這裏咱們並不關心時鐘值是如何產生的，他能夠經過本地時鐘產生，也能夠爲有序的數字。這裏咱們爲每個進程P_i定義一個時鐘C_i，該時鐘可以爲任意一個事件a分配一個時鐘值：C_i〈a〉。在全局上，一樣存在一個時鐘C，對於事件b，該時鐘可以分配一個時鐘值C〈b〉，而且若是事件b發生在進程i上，那麼有 C〈b〉=C_i〈b〉。

咱們的系統並不依賴於物理時鐘，由於物理時鐘可能會出現錯誤，所以咱們要求

時鐘條件：若是對於事件a和事件b，有a→b，那麼C〈a〉<C〈b〉。

 

可是，事件a的邏輯時鐘值小於事件b的邏輯時鐘值並不意味着有a->b，由於可能有事件a與事件b同時發生（見例3）。

另外，在圖2-X中咱們能夠獲得p2與q3同時發生，p3與q3也同時發生，那麼這意味着p2與p3同時發生。可是這與實際狀況相違背，由於p2→p3。所以，咱們給出下面兩個限制條件：

C1：若是事件a和事件b是同一個進程Pi中的事件，而且a在b以前發生，那麼有：

C_i〈a〉<C_i〈b〉

 

C2：若是a爲進程Pi上某消息發送事件， b爲進程Pj上該消息接收事件，那麼有：

C_i〈a〉<C_i〈b〉

如今咱們能夠進一步考慮下「時鐘走表」的概念，若事件a發生在事件b以前，有C〈a〉<C〈b〉，例如C〈a〉=4，C〈b〉=7，那麼在事件a和事件b之間存在4到5，5到6和6到7三個時間間隔。也就是說存在前後順序的事件之間必定至少存在至少一個時間間隔。那麼C1意味着，同一個進程中的兩個事件之間必定存在至少一個時間間隔；C2意味着，每一條消息必定跨越了至少一個時間間隔。

根據以上規則，咱們爲存在事件間隔的事件或消息之間添加一條灰色的事件線來表示時間間隔的存在，那麼圖2-X能夠轉換爲圖2，以下所示：

圖2：時間線

3  應用

下面，咱們能夠假定進程爲分佈式存儲系統或並行數據庫系統中的不一樣節點。下面咱們將時鐘的概念引入到並行系統中。在系統中，每個節點i均包含一個時鐘Ci，系統中包含兩類事件，一種爲節點上的數據更新；另外一類爲節點之間的消息通訊（或數據同步）。

下面咱們來講明，該系統是如何知足C1和C2條件的。

對於C1條件來講，系統須要知足下面的實現規則：

IR1：對於同一節點上任意的連續事件來講，該節點上的時鐘只須要保證較晚發生事件的時鐘值要大於較早發生事件的時鐘值便可。

對於C2條件來講，當節點發送消息m時，該消息須要同時攜帶發送時刻的在該節點產生的時間戳。在接收方收到該消息m以後，接收方節點所產生的時間戳要大於消息m所攜帶的時間戳。可是僅僅如此仍是不夠的，例如：

假設某節點A向節點B發送消息m，在發送消息時刻節點A的本地事件爲：15:33:30，那麼該m所攜帶的時間戳可能爲T_{m_a}=153330。節點B在接收到m後，可能設置該事件的時間戳T_{m_b}爲153400。可是因爲機器之間的時間偏差，本地時間可能爲：15:50:05。而且，在該接收m事件事前15:45:15時刻，節點B上發生數據更新事件，該事件戳爲T_{m_b’}=154515。顯然，將T_{m_b}設置爲153400將會引發邏輯上的錯誤。

那麼，爲了知足C2約束，則須要知足下面的規則：

IR2：（a）若是事件a表明節點Ni發送消息m，那麼消息m將攜帶時間戳T_m，且T_m=Ci〈a〉；（b）當節點Nj接收到消息m後，節點將設置該事件的時鐘Cj大於等於該節點上一事件的時鐘而且大於等於Tm。

 

該理論爲時間戳策略的基本理論，具體的系統和實現要根據當前環境來決定。

 

向量時鐘

 

向量時鐘（Vector Clock）[8, 9]是一種在分佈式環境中爲各類操做或事件產生偏序值的技術，它能夠檢測操做或事件的並行衝突，用來保持系統的一致性。

向量時鐘方法在分佈式系統中用於保證操做的有序性和數據的一致性。向量時鐘一般能夠被認爲是一組來自不一樣節點的時鐘值Vi[1]、Vi[2]、…、Vi[n]。在分佈式環境中，第i個節點維護某一數據的時鐘時，根據這些值能夠知道其餘節點或副本的狀態，例如Vi[0]是第i個節點所瞭解的第0個節點上的時鐘值，而Vi[n]是第i個節點所瞭解的第n個節點上的時鐘值。時鐘值表明了節點上數據的版本信息，該值能夠是來自節點本地時間的時間戳或者是根據某一規則生成有序數字。

以3副本系統爲例，該系統包含節點0、節點1和節點2。某一時刻的狀態可由表2-3來表示。

表2-3  向量時鐘實例

	V 0	V  1	V  2
V  0	4	2	0
V  1	1	4	0
V  2	0	0	1

 

 

該表表示當前時刻各節點的向量時鐘爲：

節點0：V0(4,2,0)

節點1：V1(1,4,0)

節點2：V2(0,0,1)

在表2-3中，Vi表明第i個節點上的時鐘信息，Vi[j]表示第i個節點所瞭解的第j個節點的時鐘信息。以第2行爲例，該行爲V1節點的向量時鐘（1,4,0），其中"1"表示V1節點所瞭解的V0節點上的時鐘值；"0"表示V1節點所瞭解的V2節點上的時鐘值；"4"表示V1節點自身所維護的時鐘值。

下面具體描述向量時鐘在分佈式系統中的運維規則。

規則1：

初始時，咱們將每一個節點的值設置爲0。每當有數據更新發生，該節點所維護的時鐘值將增加必定的步數d，d的值一般由系統提早設置好。

該規則代表，若是操做a在操做b以前完成，那麼a的向量時鐘值大於b向量時鐘值。

向量時鐘根據如下兩個規則進行更新。

規則2：

在節點i的數據更新以前，咱們對節點i所維護的向量Vi進行更新：

Vi[i]= Vi[i]+d（d > 0）

該規則代表，當Vi[i]處理事件時，其所維護的向量時鐘對應的自身數據版本的時鐘值將進行更新。

規則3：

當節點i向節點j發送更新消息時，將攜帶自身所瞭解的其餘節點的向量時鐘信息。節點j將根據接收到的向量與自身所瞭解的向量時鐘信息進行比對，而後進行更新：

Vj[k] = max{Vi[k], Vj[k]}

在合併時，節點j的向量時鐘每一維的值取節點i與節點j向量時鐘該維度值的較大者。

兩個向量時鐘是否存在偏序關係，經過如下規則進行比較：

對於n維向量來講，Vi > Vj，若是任意k（0≤k≤n 1）均有Vi[k] > Vj[k]。

若是Vi既不大於Vj且Vj也不大於Vi，這說明在並行操做中發生了衝突，這時須要採用衝突解決方法進行處理，好比合並。

如上所示，向量時鐘主要用來解決不一樣副本更新操做所產生的數據一致性問題，副本並不保留客戶的向量時鐘，但客戶有時須要保存所交互數據的向量時鐘。如在單調讀一致性模型中，用戶須要保存上次讀取到的數據的向量時鐘，下次讀取到的數據所維護的向量時鐘則要求比上一個向量時鐘大（即比較新的數據）。

相對於其餘方法，向量時鐘的主要優點在於：

節點之間不須要同步時鐘，即不須要全局時鐘。

不須要在全部節點上存儲、維護一段數據的版本數。

下面咱們經過一個例子來體會向量時鐘如何維護數據版本的一致性。

A、B、C、D四我的計劃下週去爬長城。A首先提議週三去，此時B給D發郵件建議週四去，他倆經過郵件聯繫後決定週四去比較好。以後C與D通電話後決定週二去。而後，A詢問B、C、D三人是否贊成週三去，C回覆說已經商量好了週二去，而B則回覆已經決定週四去，D又聯繫不上，這時A獲得不一樣的回覆。若是他們決定以最新的決定爲準，而A、B、C沒有記錄商量的時間，所以沒法肯定何時去爬長城。

下面咱們使用向量時鐘來"保證數據的一致性"：爲每一個決定附帶一個向量時鐘值，並經過時鐘值的更新來維護數據的版本。在本例中咱們設置步長d的值爲1，初始值爲0。

 

2.4.5  向量時鐘（2）

（1）在初始狀態下，將四我的（四個節點）根據規則1將自身所維護的向量時鐘清零，以下所示：

A(0,0,0,0)

B(0,0,0,0)

C(0,0,0,0)

D(0,0,0,0)

（2）A提議週三出去

A首先根據規則2對自身所維護的時鐘值進行更新，同時將該向量時鐘發往其餘節點。B、C、D節點在接收到A所發來的時鐘向量後發現它們所知曉的A節點向量時鐘版本已通過時，所以一樣進行更新。更新後的向量時鐘狀態以下所示：

A(1,0,0,0)

B(1,0,0,0)

C(1,0,0,0)

D(1,0,0,0)

（3）B和D經過郵件進行協商

B以爲週四去比較好，那麼此時B首先根據規則2更新向量時鐘版本（B(1,1,0,0)），而後將向量時鐘信息發送給D（D(1,0,0,0)）。D經過與B進行版本比對，發現B的數據較新，那麼D根據規則3對向量時鐘更新，以下所示。

A(1,0,0,0)

B(1,1,0,0)

C(1,0,0,0)

D(1,1,0,0)

（4）C和D進行電話協商

C以爲週二去比較好，那麼此時C首先更新自身向量時鐘版本（C(1, 0, 1, 0)），而後打電話通知D（D(1, 1, 0, 0)）。D根據規則3對向量時鐘進行更新。

此時系統的向量時鐘以下所示：

A(1,0,0,0)

B(1,1,0,0)

C(1,0,1,0)

D(1,1,1,0)

最終，經過對各個節點的向量時鐘進行比對，發現D的向量時鐘與其餘節點相比具備偏序關係。所以該系統將決定"週二"一塊兒去登山。

下面咱們用圖示來描述上述過程，如圖2-5所示。

該方法中數據版本可能出現衝突，即不能肯定向量時鐘的偏序關係。如圖2-5所示，假如C在決定週三登山後並無將該決定告訴其餘人，那麼系統在此刻將不能肯定某一數據向量時鐘的絕對偏序關係。比較簡單的衝突解決方案是隨機選擇一個數據的版本返回給用戶。而在Dynamo中系統將數據的不一致性衝突交給客戶端來解決。當用戶查詢某一數據的最新版本時，若發生數據衝突，系統將把全部版本的數據返回給客戶端，交由客戶端進行處理。

該方法的主要缺點就是向量時鐘值的大小與參與的用戶有關，在分佈式系統中參與的用戶不少，隨着時間的推移，向量時鐘值會增加到很大。一些系統中爲向量時鐘記錄時間戳，某一時間根據記錄的時間對向量時鐘值進行裁剪，刪除最先記錄的字段。

向量時鐘在實現中有兩個主要問題：如何肯定持有向量時鐘值的用戶，如何防止向量時鐘值隨着時間不斷增加。

 

2.5  小結

本章介紹了關於海量數據存儲以及NoSQL數據庫中的數據一致性理論。CAP理論爲NoSQL數據管理系統的基石，該理論告訴咱們強一致性、可用性和分區容錯性不能同時知足。在進行系統設計的時候必須在這三者之間作出權衡，需根據不一樣的應用和環境進行系統設計。

爲了提升系統的效率，在大多數的系統中採用的是"最終一致性策略"，而放棄了CAP理論中的"強一致性"要求。BASE模型正是這一方面應用的典型理論表明，該方法經過犧牲一致性和孤立性來提升可用性和系統性能，其中BASE分別表明：基本可用、軟狀態和最終一致性。

在數據一致性的最終實現上，不一樣的系統採用不一樣的策略，包括：Quorum的NWR策略、兩階段提交協議、Paxos、時間戳、向量時鐘等，本章只列舉了其中的一部分，現實中還有更多的實現。可是這些系統或者模型均以CAP理論爲基石，並依據不一樣的狀況做出權衡，例如Paxos具備較強的一致性，可是系統延遲較大。此外，不少系統中採用多種策略的結合，例如，NWR策略常常與向量時鐘一同使用，用以解決數據的一致性問題。