时间戳和向量图
时间戳策略
摘自《大数据挑战与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中，事件p2发生在事件p1之后，因此有p1→p2。
例2：对于事件q1和时间p3，由于存在从q1到p2的消息传递，因此有q1→p2，同时在同一进程P中，我们知道p2→p3，因此根据该模型，有q1→p3。
例3：对于事件p3和事件q3，在逻辑上，我们不能确定p3是否在q3之前发生（只能得出p3在q1之前发生），也不能确定q3是否在p3之前发生（只能得出）q3在p1之前发生。尽管在物理时间上，q3要先于p3发生，但是我们不能确定两事件在该模型下的逻辑关系，因此我们说p3和q3同时发生。
2 逻辑时钟
现在我们将时钟引入到系统中。这里我们并不关心时钟值是如何产生的，他可以通过本地时钟产生，也可以为有序的数字。这里我们为每一个进程Pi定义一个时钟Ci，该时钟能够为任意一个事件a分配一个时钟值：Ci〈a〉。在全局上，同样存在一个时钟C，对于事件b，该时钟能够分配一个时钟值C〈b〉，并且如果事件b发生在进程i上，那么有 C〈b〉=Ci〈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之前发生，那么有：
Ci〈a〉<Ci〈b〉
C2：如果a为进程Pi上某消息发送事件， b为进程Pj上该消息接收事件，那么有：
Ci〈a〉<Ci〈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所携带的时间戳可能为Tm_a=153330。节点B在接收到m后，可能设置该事件的时间戳Tm_b为153400。但是由于机器之间的时间误差，本地时间可能为：15:50:05。并且，在该接收m事件事前15:45:15时刻，节点B上发生数据更新事件，该事件戳为Tm_b’=154515。显然，将Tm_b设置为153400将会引起逻辑上的错误。
那么，为了满足C2约束，则需要满足下面的规则：
IR2：（a）如果事件a代表节点Ni发送消息m，那么消息m将携带时间戳Tm，且Tm=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 向量时钟实例
|
|
V0
|
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策略经常与向量时钟一同使用，用以解决数据的一致性问题。
