理论之CAP，BASE，Quorum，2PC，3PC，paxos

分布式环境的各种问题

• 1 并发性问题 当多个节点并发操作共享资源的时候，怎么准确并且高效的协调分布式并发操作
• 2 时序性问题 很难判断事件的发生先后问题。缺乏一个全局时钟序列的控制。
• 3 高可用性问题 由于分布式系统，故障经常发生。
• 4 通信异常问题 一次网络通信的延时大概在0.1--1ms之间。如何解决消息丢失，消息延迟问题
• 5 数据一致性问题 局部小集群完成了本来需要完整系统才能完成的问题。（脑裂），如何保证数据一致性问题
• 6 分布式事务问题 原来是数据库对并发访问的请求隔离，能互不干扰对方。

CAP理论

一致性（C，Consistency）、可用性（A， Availability）、分区容忍性（P，Partition Tolerance）
一致性指的是，每次读取操作，都能读取到最新的一次写入。
可用性指的是，每次请求数据，都能及时的得到响应。但是并不要求，这个数据是最新一次写入。
分区容忍性指的是，节点node1 ,和节点node2，本来是一致的，但是由于网络故障，或者某个节点宕机，导致两边的节点，在指定时间内无法同步，数据没有一致，造成分区。所谓分区，就比如写数据，根据hash，分库分表到不同的地方。那两边的数据不一致。

image.png

CAP理论中，说是最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素，我觉得这个理论完全没有意义，只是学术上的一个理论而已。这都只是一个度的问题。就像战绩一样，

image.png

当然这里是游戏中的英雄，5项属性的强弱。系统也想游戏中的英雄一样，CAP相当于这个系统的三项属性而已。只不过属性值不一样而已，A值高叫高可用系统。
HA 和HP特性区别
1、A(可用性)：高可用性简单地说就是系统的稳定性+抗容灾能力，假设一个节点挂，另一个备份节点要顶上
2、P(分区容忍性) ，不是分区容错性，容错由A的问题。在实际应用中指的是集群架构和数据支持动态横向扩展。所谓动态，就是不停机。横向扩展指的是当一套系统性能达到瓶颈时，运维人员可以利用增加服务器数量，来提供系统性能。而不是购买更贵的高性能服务器。

Base 理论

Base 理论是对 CAP 中一致性和可用性权衡的结果。无法做到强一致性（Strong consistency）采用适当的方式来使系统达到最终一致性（Eventual consistency）。
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎可以在 1 秒作用返回结果。
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
什么是软状态呢？
相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

Quorum机制

先看一个极端的情况：WARO机制
WARO(Write All Read one)是一种简单的副本控制协议，当Client请求向某副本写数据时(更新数据)，只有当所有的副本都更新成功之后，这次写操作才算成功，否则视为失败。
从这里可以看出两点：①写操作很脆弱，因为只要有一个副本更新失败，此次写操作就视为失败了。②读操作很简单，因为，所有的副本更新成功，才视为更新成功，从而保证所有的副本一致。这样，只需要读任何一个副本上的数据即可。假设有N个副本，N-1个都宕机了，剩下的那个副本仍能提供读服务；但是只要有一个副本宕机了，写服务就不会成功。
WARO牺牲了更新服务的可用性，最大程度地增强了读服务的可用性。而Quorum就是更新服务和读服务之间进行一个折衷。
Quorum机制是“抽屉原理”的一个应用。定义如下：假设有N个副本，更新操作wi 在W个副本中更新成功之后，才认为此次更新操作wi 成功。称成功提交的更新操作对应的数据为：“成功提交的数据”。对于读操作而言，至少需要读R个副本才能读到此次更新的数据。其中，W+R>N ，即W和R有重叠。一般，W+R=N+1

image.png

假设系统中有5个副本，W=3，R=3。初始时数据为(V1，V1，V1，V1，V1）--成功提交的版本号为1
当某次更新操作在3个副本上成功后，就认为此次更新操作成功。数据变成：(V2，V2，V2，V1，V1）--成功提交后，版本号变成2
因此，最多只需要读3个副本，一定能够读到V2(此次更新成功的数据)。而在后台，可对剩余的V1 同步到V2，而不需要让Client知道。
Quorum机制就是只要读取N/2 +1 个节点的数据，就可以读取到最新更改的数据，只要写入N/2+1 个副本，就算写成功了，

二段提交协议（2PC）

• 1 ===============投票阶段
  • 1.1 事物询问
    协调者向所有参与者发送事物内容，询问是否可以执行事物，等待响应。
  • 1.2 执行事物
    个参与者，执行事物，并且在各自的节点上保存，事物的redo信息和undo信息
  • 1.3 反馈响应
    如果成功执行事物，则反馈给协调者YES响应，如果事物执行失败，则反馈协调者NO 响应。
    上述阶段类似于投票，失败的事物有一票否决权
• 2===============事物提交阶段
  假如投票都通过，那么发起commit请求，所有参与者提交事物。并且反馈提交结果，ack信息，释放事物资源。
  假如有个投票没有过，那么协调者发出rollbakc请求，反馈回滚结果，ack信息。事物事物资源，中断事物。

同步阻塞的优缺点
1 实现简单， 方便。
2 缺点： 同步阻塞，单点问题，脑裂，太保守。
同步阻塞是最明显的问题，各个参与者的逻辑都处于阻塞状态。
协调者，假如挂掉了，那么参与者的事物将处于锁定状态，
数据不一致。原因是，参与者都通过了第一阶段，但是提交commit请求的时候，只有部分参与者接受到（网络故障），参与者挂掉的话，必须等待超时来判断是否要中断事物。

三段提交协议（3PC）

can commit ,precommit ,do commit
把提交事物请求一分为二
CanCommit阶段
1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后等待参与者的响应。
2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

PreCommit阶段
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
1向参与者发送PreCommit请求，并进入Prepared阶段。
2.参与者执行事务操作，并将undo和redo信息记录到事务日志中。
3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。（协调者还在，但是参与者挂了，协调者等待参与者的响应ack信息，等待超时）
1.发送中断请求 协调者向所有参与者发送abort请求。
2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

doCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。
执行提交
1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3.响应反馈 事务提交完之后，向协调者发送Ack响应。

4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。

中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
1.发送中断请求 协调者向所有参与者发送abort请求
2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息
4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

2PC与3PC的区别
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

paxos 算法

首先paxos算法总的来说是一个分布式容错的状态机模型。
maxPn 代表 这个节点所接手的提案的最大提案编号。
maxAcceptn （maxAn）代表这个节点所批准的最大提案编号。简写为maxAn。
maxPn 是可能大于maxAn的，因为第一阶段过了之后，可能另外一个proposer在这个节点提出了更大的提
案编号
这个算法提出，在分布式的环境中，每一个节点都是一个状态机。在不同用户输入，但是输入顺序一样的情况下，最终得到的状态是一致的。在paxos算法中，假设某个节点A1，作为acceptor角色，在第一阶段prepare，竞选提案编号的阶段，输入的提案编号K，大于节点A1中记录的maxPn，那节点A1是作为第一节点的多数派，多数派滞后。在第二阶段，输入是拿到第一阶段所学习的最大AcceptN最大提案编号，当这个节点滞后的时候，第二阶段，通过提高maxAn来推进新的提案。当节点超前的时候，也就是maxPn大于K（ 输入的提案编号）作为少数派。这个节点，就会不回应，状态机无法向前推进，acceptN无法传送到第二阶段。自动把速度降低。最后会保证全局状态机的一致性。
第一阶段，对于提案者proposer来说是个竞选提案编号的阶段，而且从acceptor中学习到acceptor集合最新，最大批准的提案编号和值，作为第二阶段的输入。那对于acceptor来说是向前推进maxPn
第二阶段对于proposer来说，他把自己第一阶段刚学到的提案，或者自己输入的提案的编号和值，传递给acceptor，等待另外的proposer去学习。是一个两个阶段相互照应的一个过程。
具体的提案选举过程，和批准过程如下图。

image.png

具体的过程，可以看这篇文章写得很详细。
https://www.cnblogs.com/shaohef/p/4499881.html

关于paxos算法和CAP理论的联系和理解，还有和2P，3P阶段的提交的对比分析

CAP理论的应用可以很灵活，在实际的系统中，取舍的粒度可能非常小。不同的子系统可以采用CP或者AP，甚至同一个子系统内部的不同事务，也可以分别采用CP或AP。另外C和A也不是绝对的，近年流行起来的最终一致性系统就是这样的例子。根据应用的语义，可能要求非常严格的C，也可以相当的宽松。比如用户在不同的服务器上发起向在购物车中添加商品的请求，只要最后能把所有的请求合并，就能得到正确的结果。对A的要求也是很灵活的，比如二阶段提交要求所有参与事务的节点都有响应，而Paxos算法只要求多数节点可用。有的应用要求节点的响应延迟在毫秒级，有的只要求在若干秒内响应即可。
这个时候三阶段提交有可能在不同的小网络里提交不同的事务，导致不一致的出现。而且三阶段提交对每个事务都需要3次交互，时延太长。Paxos算法的先进之处在于，当且仅当大多数成员达成一致时提交事务，即使网络被分区，每个分区内的集群成员不足整个集群的多数时，就不会提交事务，反之只要分区内的节点能达到多数要求，系统就能继续运行下去。Paxos算法既不会出现二阶段提交的阻塞情况，也没有三阶段提交的不一致的风险。