CAPBASEd二阶段提交协议三阶段提交协议拜占庭将军问题paxosRaftZABNWR

Posted 2020-12-07 mike_chang

CAP定理

在分布式系统中，一致性、可用性、分区容错性最多只能同时实现两点。
一致性，分布式系统所有数据备份是否相同。
可用性，收到用户的请求，在时限内服务器必须给出明确的回应。
分区容错性：大多数分布式系统都分布在多个子网络，每个子网络就叫做一个区。分区容错指分区间通信可能失败，比如，一台服务器放在中国，另一台服务器放在美国，这两个区之间可能通信失败，系统设计的时候，必须考虑到这种情况。

---

BASE理论

由eBay架构师提出的，BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网分布式系统实践的总结，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统打到最终一致性。

---

二阶段提交协议

阶段1：请求阶段，协调者通知事务参与者准备提交或者取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地执行成功）或者取消（事务参与者本地执行失败）。
阶段2：提交阶段，协调者将基于第一个阶段的投票结果进行决策：提交或者取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行相应的操作。
两阶段提交协议可能面临两种故障
事务参与者发生故障。给每个事务设置一个超时时间，如果某个事务参与者一直不响应，到达超时时间后整个事务失败。
协调者发生故障。协调者需要将事务相关信息记录到操作日志并同步到备用协调者，假如协调者发生故障，备用协调者可以接替它完成后续的工作，可以使用paxos。

---

三阶段提交协议

三阶段提交协议是两阶段提交协议的改进版本，三阶段提交协议引入了超时机制，它通过超时机制解决了阻塞的问题。
1.询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作；超时中止事务。
2.准备阶段：如果在询问阶段所有参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，但是不提交操作；超时中止事务。
3.提交阶段：如果每个参与者在准备阶段返回成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回失败，协调者向参与者发起中止命令，执行undo日志，释放锁定的资源；如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。

---

拜占庭将军问题

“在存在消息丢失的不可靠信道上，试图通过消息传递的方式达到一致性是不可能的”。因此，在系统中存在除了消息延迟或不可送达的故障以外的错误，包括消息被篡改、节点不按照协议进行处理等问题，将会潜在地会对系统造成针对性的破坏。

解决方案：
非对称加密技术
系统中任何人都是不可靠的，当一个人收到其他人的消息后，不需要立即做出判断，而是把自己收到的消息再传递给另外的人，这样，消息在各个成员之间就是透明的。因为系统中诚实的节点占多数，所以每个人根据总信息对比后进行判断，最终出现差错的可能性就会大大降低。

---

Paxos

作用：取值一致性，多副本的更新操作序列[opration1，opration2，opration3]需要相同，用Paxos确定操作序列oparationi。

应用：
Google Chubby分布式锁服务采用了Paxos来对数据副本的更新序列达成一致。
客户端找到Chubby Master，向其发送请求。针对写请求，Chubby Master采用一致性协议将其广播给集群中所有的副本服务器，并在过半的服务器接受了写请求后，再响应给客户端正确的应答。对于读请求，不需要广播，直接由master单独处理。
Chubby的数据结构可以看作是一个由目录和文件组成的树的文件系统，可以使用带有斜杠的字符串表示一个节点。
Chubby用来对master进行选举
ZooKeeper是Chubby的开源实现。

Paxos算法详解：
Paxos容错性：可以容忍任意提案人Proposer故障；可以容忍半数以下的Acceptor故障。
Paxos组成：系统内由多个Acceptor组成，负责存储和管理变量var；外部有多个Proposer任意并发调用API，向系统提交不同的var值。

Paxos一致性：如果var的值没有确定，则为null；一旦确定，则不可更改，后者认同前者。
Paxos避免死锁：比如，一个Proposer首先获取到一个Acceptor的互斥锁，接着在这个proposer释放此锁之前自己挂掉了，因为它的锁还没有释放，所以其它的Proposer都永远不能获取到锁。采用并发的抢占式的，发送议案编号的方式避免死锁。每个议案编号全局唯一，递增。

阶段一：
Proposer调用Acceptor::prepared(议案编号);
Proposer向Acceptor发送议案编号以申请访问权限；Acceptor采用喜新厌旧的方式处理这一阶段的请求，当新编号大于旧编号时，把新编号赋值给maxN，并返回var的值，此时旧访问权失效，不再接受旧提交，只接受新提交；当新编号不大于旧编号时，Acceptor忽略此次请求，此次请求失效。
阶段二：
Proposer调用Acceptor::accept(议案编号，议案内容);
Proposer向Acceptor发送提案请求批准；Acceptor接受到提案后，首先验证，当Proposer的编号 == maxN，设置值；当Proposer的编号 < maxN，当前请求失效。

议案编号的作用：获取访问权限、避免死锁

活锁：延时，Leader（唯一的proposer）

获取提案
方案一：半数以上的Acceptor向每个Learner发送结果，m*n
方案二：半数以上的Acceptor向一个作为Leader的Learner发送结果，该Learner再同步到其它的Learners，m+1，单点故障
方案三：半数以上的Acceptor向一个Learner集合发送结果，learner集合的容量越大，可靠性越好，网络通信复杂度更高

Multi Paxos算法(Paxos选主)
Multi Paxos先选出master，然后由master提交一次prepare->promise，之后所有请求直接执行propose->accept就可以了。
在Paxos中，需要进行一轮或多轮“prepare->promise->propose->accept”这样完整的二阶段请求过程来选定提案。

---

Raft算法
随机时钟选主
master不断给其他单元发送心跳包，如果有请求过来，心跳包里同时把数据发过去，二阶段提交
https://raft.github.io/ // 右击服务器，点击quest

---

ZAB原子广播协议
把有最大事务ID的节点选为主
二阶段提交
原子广播过程：
1、leader从客户端接收一个请求
2、leader生成一个新事务，并为此事务生成一个事务ID，接着把事务通知给其它follower；follower接收到此请求后，把事务ID加入一个队列里，并执行事务，最后响应leader
3、leader收到半数确定，发送提交请求；follower在提交此事务前，会判断此事务ID是不是比队列中所有的事务ID都小，如果是则提交；如果不是，等待更小的事务的提交命令。
ZAB除了事务ID，还在一个LeaderID。

---

一致性算法还有一种多数派的方式NWR，一半以上写入成功就成功

NWR，操作序列不一致
事务a，set0
事务b, set5
结果：db1 --> set5, set0 --> 0
db2 --> set5, set0 --> 0
db3 --> set0, set5 --> 5