时间戳和向量图

时间戳策略

摘自《大数据挑战与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策略常常与向量时钟一同使用，用以解决数据的一致性问题。