分布式系统的一致性与共识算法(二)

Consitency

背景

如买最后一张车票，两个售票处分别通过某种方式确认过这张票的存在。这时，两家售票处几乎同时分别来了一个乘客要买这张票，从各自"观察"看来，自己一方的乘客都是先到的，这种情况下，怎么能达成对结果的共识呢？看起来很容易，卖给物理时间上率先提交请求的乘客即可。然而，对于两个来自不同位置的请求来说，要判断在时间上的"先后"关系并不是那么容易。两个车站的时钟时刻可能是不一致的。时钟计时可能不精确的。根据相对论的观点，不同空间位置的时间是不一致的。因此追求绝对时间戳的方案是不可行的，能做的是要对事件的发生进行排序。这也是解决分布式系统领域很多问题的核心秘诀，把不同时空发生的多个事件进行全局唯一排序，而这个顺序还得是大家都认可的。排了序，一个一个处理就行了，和单机没有任何区别(不考虑突然故障情况，只考虑共识机制)如果存在可靠的物理时钟，实现排序往往更为简单。高精度的石英钟的漂移率为10的-7次方，最准确的原子震荡时钟的漂移率为10的-13次方。Google曾在其分布式数据库Spanner中采用基于原子时钟和GPS的"TrueTIme"方案，能够将不同数据中心的事件偏差控制在10ms知心区间。在不考虑成本的前提下，这种方案简单、有效。然而，计算机系统的时钟误差要大得多，这就造成分布式系统达成一致顺序十分具有挑战性，或者说基本不可能。要实现绝对理想的严格一致性(Strict Consistency)代价很大。除非系统不发生任何故障，而且所有节点之间的通信无需任何时间，此时整个系统其实就等价于一台机器了，因此根据实际需求的可用，人们可能选择不同强度的一致性。

顺序一致性(Sequential Consistency)

虽然强度上线性一致性 > 顺序一致性，但因为顺序一致性出现的时间比较早(1979年)，线性是在顺序的基础上的加强(1990年)。因此先介绍下顺序一致性。
顺序一致性也算强一致性的一种，它的原理比较晦涩。

举例说明1:下面的图满足了顺序一致，但不满足线性一致

在这里插入图片描述

1.x和y的初始值为0
2.Write(x,4)代表写入x=4，Read(y,2)为读取y=2

从图上看，进程P1，P2的一致性并没有冲突。因为从这两个进程的角度来看，顺序应该是这样的。

Write(y,2), Read(x,0), Write(x,4), Read(y,2)

这个顺序对于两个进程内部的读写顺序都是合理的，只是这个顺序与全局时钟下看到的顺序并不一样。在全局时钟的观点来看，P2进程对变量X的读操作在P1进程对变量X的写操作之后，然而P2读出来的却是就数据0

举例说明2:

假设我们有个分布式KV系统，以下是四个进程对其的操作顺序和结果:
-表示持续的时间，因为一次写入或者读取，客户端从发起到响应是由时间的，发起早的客户端，不一定拿到数据就早，有可能因为网络延迟反而更晚。
情况1:

A:--W(x,1)------------------------
B:  --W(x,2)------------------------
C:                                   -R(x,1)-         --R(x,2)-
D:                     -R(x,1)-              --R(x,2)--

情况2

A:--W(x,1)------------------------
B:  --W(x,2)------------------------
C:                                 -R(x,2)-        --R(x,1)--
D:                          -R(x,2)-          --R(x,1)--

上面情况1和2都是满足顺序一致性的，C和D拿到的顺序都是1-2或2-1，只要CD的顺序一致，就是满足顺序一致性。只是从全局看来，情况1更真实，情况2就显得"错误"了，因为情况2是这样的顺序

B W(x,2) -> A W(x,1) -> C R(x,2) -> D R(x,2) -> C R(x,1) -> D R(x,1)

不过一致性不保证正确性，所以这仍然是一个顺序一致，再加一种情况3

A:--W(x,1)------------------------
B:  --W(x,2)------------------------
C:                            -R(x,2)             --R(x,1)-
D:                      -R(x,1)-            --R(x,2)--

情况3就不属于顺序一致了，因为C和D两个进程的读取顺序不同了，回到情况2，C和D拿数据发起的时间是不同的，且有重叠，有可能C拿到1的时候，D已经拿到了2，这就导致了不同的客户端在相同的时间获取了不一样的数据，但其实这种模式在现实中的用的听广泛的:
如，你在Twitter上写了两条推文，你的操作会耗费一定的时间渗透进一层层的缓存系统，不同的朋友将在不同的时间看到你的信息，但每个朋友都会以相同顺序看到了你的两条推文，不会是乱序。只是一个朋友已经看到了第二条，一个朋友才刚看到第一条，不过没关系，它总会看到两条，顺序没错就行，无伤大雅。但有些时候，顺序一致性是不满足要求的

举例说明3：

在这里插入图片描述

从时间轴上可以看到，B0发生在A0之前，读取到的x值为0.B2发生A0之后，读取到的x值为1.而读操作B1,C0,C1与写操作A0在时间轴上有重叠，因此它们可能读取到旧的值0，也可能读取到新的值1，注意，C1发生在B1之后(二者在时间轴上没有重叠)，但是B1看到x的新值，C1反而看到的是旧值。对于用户来说，x的值发生了回调。即要求任何一次读都能读取到最新数据，和全局时钟一致，对比例1，既满足顺序一致又满足线性一致应该是这样的。如图所示。在这里插入图片描述