参考文献：

Lamport’s logical clock

这章重点介绍了分布式系统下各种类型的时序，其实在分布式场景下并不需要确切的时间，我们只是需要时间来对事件进行排序ordering. 并且还聊到了哪种order顺序是正确correct的，这其实没有绝对的定论，而是要根据各种场景选择合适的顺序，重点在于不同的节点对于正确性correctness的定义需要一致。

Total order

all replicas process messages in same order, 对于多个replica节点来说，所有的replica节点都遵循相同的处理顺序，但是不一定服从real-time，也就是不一定和client发来的处理顺序一致。

Implementation of total order

Total-order是可以实现的，不过需要选出一个leader，并且每次分发消息的时候都需要一个时间戳。

Linearizability

total order + respect the real-time，在total order的情况下加上了real-time的要求，即和client发来的处理顺序一致，并且所有replicas都是相同的处理顺序。

linearizability是没法在distributed system分布式系统中实现的，这里有个CAP的理论，参考轻松理解CAP理论，简单来说就是在P的场景下，无法保证C和A同时成立，除非有特殊的场景设计，比如Google对P的场景进行了独特的设计。

但是linearizability却可以在parallel system并行系统中实现，因为这个系统是个同步的场景synchronous setting，并且parallel system就应当保证linearizability的唯一正确性。

FIFO rder

different servers can get different orders as long as the order from the same client is preserved. 这里强调了多个client的要求，对于多个replica server来说，他们是可以按不同的顺序处理消息的，但是对于给他们发消息的每个client，每个服务器server需要按client发来的消息一样的顺序对消息进行处理。

Implementation of FIFO-order

同样可以在distributed system中实现，clients需要维护一个本地的计数器，server端需要为每一个client维护一个处理队列。

Happen-before ordering

可以通过逻辑表示出发送方和接收方的顺序关系。

这里我们重点关注如何在日志中记录这种前后关系，也就是采用了Lamport’s Logical Clock的方法如下：

简单理解来看，对于同一个process的先后事件，后一个事件为前一个LC++，对于不同process具有happen-before关系的事件，后一个事件也为前一个LC++，最终该事件的LC为这两个值中的max.

但是这种记录方法有它的局限性，即当LC(x)<LC(y)的时候，我们不一定可以推出x一定先于y发生，即x<y，也可能会出现x和y同时发生，如图中(f,1)和(i,2)可能会同时发生，但是x绝不会晚于y发生。这也表明logical clock不能完全展现出事件之间的因果关系causality。

Causal ordering

Causal ordering可以表示不同进程间的因果关系，下面这个例子很生动，如果我们只是维持FIFO order，那么分别保证了mother(client)的顺序和father(client)的顺序，但是它们两者综合起来看就会产生意想不到的后果。因此我们需要一种因果关系去表征不同process间的关系，这就是causal relationship。

在实现上，采取了vector clock这种时钟，VC不是一个值，而是一个有N个分量的向量，其中N是processors的个数。在进行更新的时候，和Logistic Clock一样是取最大值，不过是对每一个分量都要取当前的最大值；对于先后事件时间中$T_j$的加1，也是针对一个分量，该分量是receiver所在的第$j$个processor代表的分量。

Summary