一致性模型及一致性协议
一、一致性模型概念
提到分布式架构就一定绕不开“一致性”问题，而“一致性”其实又包含了数据一致性和事务一致性两种情况，下面是对强一致性、最终一致性、因果一致性、单调读一致性、单调写一致性、会话一致性的解释。
1.1 强一致性：在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求，也是最难实现的。关系型数据库更新操作就是这个案例。关系型数据库的强一致性其实也就是事务的特性，事务是一组操作的执行单元，相对于数据库操作来讲，事务管理的是一组SQL指令，比如增加，修改，删除等，事务的一致性要求这个事务内的操作必须全部执行成功，如果在此过程种出现了差错，比如有一条SQL语句没有执行成功，那么这一组操作都将全部回滚。
最经典的例子便是：A向B汇款500元，B账户多了500元，这整个过程，要么全部正常执行，要么全部回滚，不然就会出现A扣款，B收不到钱，或者A没扣款，B收到500元的情况，这种场景是灾难性的。
事务ACID特性
原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
一致性（Consistency）
事务前后数据的完整性必须保持一致。
隔离性（Isolation）
事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。
持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响
1.2. 最终一致性：和强一致性相对，在某一时刻用户或者进程查询到的数据可能都不同，但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。
1.3. 因果一致性：因果一致性发生在进程之间有相互依赖关系的情形下。例如AB两个进程相互依赖，那么如果A对某个变量进行更新，他在更新之后会通知B，这时候B看到的就是新值，但是如果还有进程C，那么C看到的值可能还是旧值。
1.4. 单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回该值之前的值。
1.5. 单调写一致性：系统保证来自同一个进程的写操作顺序执行。
1.6 .会话一致性：提交更新操作的用户在同一个会话里读取该数据时能够保证数据是最新，
二、CAP原则
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。
事实上我们在设计分布式系统是都会考虑到bug,硬件，网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，我们要求整个系统还是要继续使用的(不继续使用,相当于只有一个分区,那么也就没有后续的一致性和可用性了)
可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。
一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。
(1) CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。
(2) CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。
(3) AP: 优先保证可用性和分区容错性，放弃一致性。NoSQL中的Cassandra 就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。
三、一致性协议
3.1 Zab协议
Zab协议 的全称是 Zookeeper Atomic Broadcast （Zookeeper原子广播）。ZAB 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致
就这样，客户端发送来的写请求，全部给Leader，然后leader再转给Follower。这时候需要解决两个问题：
（1）leader服务器是如何把数据更新到所有的Follower的。
（2）Leader服务器突然间失效了，怎么办？
因此ZAB协议为了解决上面两个问题，Zab 协议设计包括两种基本的模式：崩溃恢复 和 消息广播：
（1）消息广播模式：把数据更新到所有的Follower
（2）崩溃恢复模式：Leader发生崩溃时，如何恢复
协议过程
当整个集群启动过程中，或者当 Leader 服务器出现网络中弄断、崩溃退出或重启等异常时，Zab协议就会 进入崩溃恢复模式，选举产生新的Leader。
当选举产生了新的 Leader，同时集群中有过半的机器与该 Leader 服务器完成了状态同步（即数据同步）之后，Zab协议就会退出崩溃恢复模式，进入消息广播模式。
这时，如果有一台遵守Zab协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么该新加入的服务器自动进入恢复模式：找到Leader服务器，并且完成数据同步。同步完成后，作为新的Follower一起参与到消息广播流程中。
协议状态切换
当Leader出现崩溃退出或者机器重启，亦或是集群中不存在超过半数的服务器与Leader保存正常通信，Zab就会再一次进入崩溃恢复，发起新一轮Leader选举并实现数据同步。同步完成后又会进入消息广播模式，接收事务请求。
保证消息有序
在整个消息广播中，Leader会将每一个事务请求转换成对应的 proposal 来进行广播，并且在广播 事务Proposal 之前，Leader服务器会首先为这个事务Proposal分配一个全局单递增的唯一ID，称之为事务ID（即zxid），由于Zab协议需要保证每一个消息的严格的顺序关系，因此必须将每一个proposal按照其zxid的先后顺序进行排序和处理。
消息广播
1）在zookeeper集群中，数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二段提交相似，但是却又不同。二段提交要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功，要么全部失败。二段提交会产生严重的阻塞问题。
2）Zab协议中 Leader 等待 Follower 的ACK反馈消息是指“只要半数以上的Follower成功反馈即可，不需要收到全部Follower反馈”
消息广播具体步骤
1）客户端发起一个写操作请求。
2）Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的ID，即zxid。
3）Leader 服务器为每个 Follower 服务器分配一个单独的队列，然后将需要广播的 Proposal 依次放到队列中取，并且根据 FIFO 策略进行消息发送。
4）Follower 接收到 Proposal 后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向 Leader 反馈一个 Ack 响应消息。
5）Leader 接收到超过半数以上 Follower 的 Ack 响应消息后，即认为消息发送成功，可以发送 commit 消息。
6）Leader 向所有 Follower 广播 commit 消息，同时自身也会完成事务提交。Follower 接收到 commit 消息后，会将上一条事务提交。
zookeeper 采用 Zab 协议的核心，就是只要有一台服务器提交了 Proposal，就要确保所有的服务器最终都能正确提交 Proposal。这也是 CAP/BASE 实现最终一致性的一个体现。
Leader 服务器与每一个 Follower 服务器之间都维护了一个单独的 FIFO 消息队列进行收发消息，使用队列消息可以做到异步解耦。 Leader 和 Follower 之间只需要往队列中发消息即可。如果使用同步的方式会引起阻塞，性能要下降很多。
崩溃恢复
一旦 Leader 服务器出现崩溃或者由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式。
在 Zab 协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的 Leader 服务器。因此 Zab 协议需要一个高效且可靠的 Leader 选举算法，从而确保能够快速选举出新的 Leader 。
Leader 选举算法不仅仅需要让 Leader 自己知道自己已经被选举为 Leader ，同时还需要让集群中的所有其他机器也能够快速感知到选举产生的新 Leader 服务器。
崩溃恢复主要包括两部分：Leader选举 和 数据恢复。
特殊情况下需要解决的两个问题：
问题一：已经被处理的事务请求（proposal）不能丢（commit的）当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。但是如果在各个 follower 在收到 COMMIT 命令前 leader 就挂了，导致剩下的服务器并没有执行都这条消息。如何解决 已经被处理的事务请求（proposal）不能丢（commit的） 呢？
2、新的 leader 将自己事务日志中 proposal 但未 COMMIT 的消息处理。
当 leader 接收到消息请求生成 proposal 后就挂了，其他 follower 并没有收到此 proposal，因此经过恢复模式重新选了 leader 后，这条消息是被跳过的。 此时，之前挂了的 leader 重新启动并注册成了 follower，他保留了被跳过消息的 proposal 状态，与整个系统的状态是不一致的，需要将其删除。如果解决呢？
这样设计的好处是旧的 leader 挂了后重启，它不会被选举为 leader，因为此时它的 zxid 肯定小于当前的新 leader。当旧的 leader 作为 follower 接入新的 leader 后，新的 leader 会让它将所有的拥有旧的 epoch 号的未被 COMMIT 的 proposal 清除。
3.2 两阶段提交协议2PC(two-phase commit)，即二阶段提交，是分布式事务中一个很重要的协议，当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个coordinator，即协调者作为的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交或回滚。
两阶段提交是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点：一个是中心化协调者节点（coordinator）和N个参与者节点（partcipant）。两个阶段：第一阶段：投票阶段 和第二阶段：提交/执行阶段。举例 订单服务A，需要调用 支付服务B 去支付，支付成功则处理购物订单为待发货状态，否则就需要将购物订单处理为失败状态。
1、第一阶段：投票阶
第一阶段主要分为3步
1）事务询问
协调者 向所有的 参与者 发送事务预处理请求，称之为Prepare，并开始等待各 参与者 的响应。
2）执行本地事务
各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者 报告说：“我这边可以处理了/我这边不能处理”。.
3）各参与者向协调者反馈事务询问的响应
如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。
第一阶段执行完后，会有两种可能。1、所有都返回Yes. 2、有一个或者多个返回No。
2、第二阶段：提交/执行阶段（成功流程）
成功条件：所有参与者都返回Yes。
第二阶段主要分为两步
1)所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交,协调者向所有参与者节点发出Commit请求.
2)事务提交参与者收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。
3、第二阶段：提交/执行阶段（异常流程）
异常条件：任何一个 参与者 向 协调者 反馈了 No 响应,或者等待超时之后,协调者尚未收到所有参与者的反馈响应。
异常流程第二阶段也分为两步
1)发送回滚请求
协调者 向所有参与者节点发出 RoollBack 请求.
2)事务回滚
参与者 接收到RoollBack请求后,会回滚本地事务。
结论：不管最后结果如何，第二阶段都会结束当前事务。
建议：少使用分布式事务，在分布式事务这个问题上，还很少有成熟牛逼的产品，而且分布式事务过程中，涉及到了各个节点的通知，二次通知，当节点多的时候，协调者的压力巨大，而且整个流程对业务的时间开销是巨大的，所以建议谨慎使用分布式事务，即使二阶段看似能处理好分布式节点的ACID问题，但是其本身也存在不小的问题。
1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
3.3 向量时钟协议
先说一下需要用到向量时钟的场景。我们在写数据时候，经常希望数据不要存储在单点。如db1，db2都可以同时提供写服务，并且都存有全量数据。而client不管是写哪一个db都不用担心数据写乱问题。但是现实场景中往往会碰到并行同时修改。导致db1和db2数据不一致。于是乎就有人想出一些解决策略。向量时钟算是其中一种。简单易懂。但是并没有彻底解决冲突问题，现实分布式存储补充了很多额外技巧。
这里反向叙述方式, 介绍向量时钟。先举实际例子让读者有个感性认识，然后再说算法规则。
1、举个例子
向量时钟实际是一组版本号（版本号=逻辑时钟)，假设数据需要存放3份，需要3台db存储（用A，B，C表示），那么向量维度就是3，每个db有一个版本号，从0开始，这样就形成了一个向量版本[A:0, B:0, C:0];
Step 1： 初始状态下，所有机器都是[A:0, B:0, C:0]；
DB_A——> [A:0, B:0, C:0]
DB_B——> [A:0, B:0, C:0]
DB_C——> [A:0, B:0, C:0]
Step 2: 假设现在应用是一个商场，现在录入一个iphone6 price 5888； 客户端随机选择一个db机器写入。现假设选择了A。,数据大概是这样 ：
{key=iphone_price; value=5888; vclk=[A:1,B:0,C:0]}
Step 3: 接下来A会把数据同步给B和C；于是最终同步结果如下
DB_A——> {key=iphone_price; value=5888; vclk=[A:1,B:0,C:0]}
DB_B——> {key=iphone_price; value=6888; vclk=[A:1, B:0,C:0]}
DB_C——> {key=iphone_price; value=5888; vclk=[A:1,B:0,C:0]}
Step 4：过了分钟，价格出现波动，升值到6888；于是某个业务员更新价格。这时候系统随机选择了B做为写入存储，于是结果看起来是这样：
DB_A——> {key=iphone_price; value=5888; vclk=[A:1,B:0,C:0]}
DB_B——> {key=iphone_price; value=6888; vclk=[A:1,B:1,C:0]}
DB_C——> {key=iphone_price; value=5888; vclk=[A:1,B:0,C:0]}
Step 5：于是B就把更新同步给其他几个存储
DB_A——> {key=iphone_price; value=6888; vclk=[A:1,B:1,C:0]}
DB_B——> {key=iphone_price; value=6888; vclk=[A:1,B:1,C:0]}
DB_C——> {key=iphone_price; value=6888; vclk=[A:1,B:1,C:0]}
到目前为止都是正常同步，下面开始演示一下不正常的情况。
Step 6：价格再次发生波动，变成4000，这次选择C写入：
DB_A——> {key=iphone_price; value=6888; vclk=[A:1, B:1,C:0]}
DB_B——> {key=iphone_price; value=6888; vclk=[A:1,B:1,C:0]}
DB_C——> {key=iphone_price; value=4000; vclk=[A:1, B:1,C:1]}
Step 7: C把更新同步给A和B，因为某些问题，只同步到A，结果如下：
DB_A——> {key=iphone_price; value=4000; vclk=[A:1, B:1,C:1]}
DB_B——> {key=iphone_price; value=6888; vclk=[A:1,B:1,C:0]}
DB_C——> {key=iphone_price; value=4000; vclk=[A:1, B:1,C:1]}
Step 8：价格再次波动，变成6000元，系统选择B写入
DB_A——> {key=iphone_price; value=6888; vclk=[A:1, B:1,C:1]}
DB_B——> {key=iphone_price; value=6000; vclk=[A:1,B:2, C:0]}
DB_C——> {key=iphone_price; value=4000; vclk=[A:1, B:1,C:1]}
Step 9： 当B同步更新给A和C时候就出现问题了，A自己的向量时钟是[A:1, B:1,C:1]， 而收到更新消息携带过来的向量时钟是[A:1,B:2, C:0], B:2 比B:1新，但是C:0却比C1旧。这时候发生不一致冲突。不一致问题如何解决？向量时钟策略并没有给出解决版本，留给用户自己去解决，只是告诉你目前数据存在冲突。
2、规则介绍
版本号变更规则其实就2条，比较简单
1、 每次修改数据，本节点的版本号 加1，例如上述step 8中 向B写入，于是从B:1变成B:2,其他节点的版本号不发生变更。
2、 每次同步数据(这里需要注意，同步和修改是不一样的写操作哦),会有三种情况：
a： 本节点的向量版本都要比消息携带过来的向量版本低（小于或等于） 如本节点为[A:1, B:2,C:3]}， 消息携带过来为[A:1, B:2,C:4]或[A:2, B:3,C:4]等。 这时候合并规则取每个分量的最大值。
b: 本节点的向量版本都要比比消息携带过来的向量版本高，这时候可以认为本地数据比同步过来的数据要新，直接丢弃要同步的版本。
c: 出现冲突，如上述step 9中，有的分量版本大，有的分量版本小，无法判断出来到底谁是最新版本。就要进行冲突仲裁。
3、冲突解决
其实没有一个比较好的解决冲突的版本：就笔者目前所了解，加上时间戳算是一个策略。具体方法是再加一个维度信息：数据更新的时间戳（timestamp）。[A:1, B:2,C:4，ts:123434354] ，如果发生冲突，再比较一下两个数据的ts，大的数值说明比较后更新，选择它作为最终数据。并对向量时钟进行订正。
3.4 Raft协议
在说Raft协议之前先说一下态机复制（State Machine Replication）， 状态机复制的理论基础是：如果集群里的每一个节点上都运行着相同的确定性状态机S，并且所有的状态机刚开始都处于同样的初始状态s0，那么给予这些状态机相同的输入序列: {i1, i2, i3, i4, i5, i6, …, in}, 这些状态机必然会经过相同的状态转换路径: s0->s1->s2->s3->…->sn最终达到相同的状态sn, 同时生成相同的输出序列 {o1(s1), o2(s2), o3(s3), …, on(sn)}。
状态机复制在实际应用中的一个例子就是MySQL集群。我们知道，MySQL集群中的master会把所有的操作记录到binlog中，这里的操作就是输入序列I, 然后slave会把master上的binlog复制到自己的relaylog中，然后把把relaylog里的操作回放一遍（相当于执行了一遍输入序列I）。所以，如果master和slave里的状态机是完全相同的，并且在执行序列I之前都处于相同的状态下，那么执行完序列I后，它们的状态依旧是相同的（一致性）。
在执行输入序列I的过程中，根据同步方式的不同，系统就有了强一致性和最终一致性。如果我们要求对于序列I中的每一个in, 都需要所有的服务副本确认成功执行了in，才能执行in+1，那么这个系统就是强一致性的系统。如果我们取消掉这个限制，仅仅要求所有的服务副本执行相同的输入序列I，但是完全各自独立执行，而不需要在中间同步，那么就有了最终一致性（各服务都会达到相同的最终状态，但是达到的时间不确定）。
参考https://blog.csdn.net/weixin_43778179/article/details/90612726
