分布式一致性算法（Paxos、Raft、ZAB）
仅用作自己记录
CAP理论
-
一般来说，对于一个分布式系统，不能同时满足以下三点：
- Consistency (一致性)
- Availability (可用性)
- Partition Tolerance (分区容错性)
-
典型例子
一致性 可用性 分区容错性 DataBase 高 高 低 RDBMS(MySQL、PostgreSQL等) 高 低 高 HBase、MongoDB、Redis 低 高 高 Cassandra -
解释
- MySQL中，部分节点挂了，导致集群无法正常提供服务，这就是分区容错性低（不具备数据冗余性）
- HBase存在主节点，一但主节点挂了，将无法使用，这叫可用性低
- Cassandra的数据存储采用Gossip协议，实现的是弱一致性（最终一致性，即一条请求的发送进入数据库，到全数据库数据最终一样，需要一定时间），即一致性低
BASE理论
- Basically Available (基本可用)
- Soft state (软状态)
- Eventually consistent (最终一致性)
一致性模型
-
强一致性（原子一致性、线性一致性）
- 在任意时刻，所有节点中的数据是一样的
- 任何一次读都能读到某个数据的最近一次写的数据
- 和全局时钟下的顺序一致
-
顺序一致性
- 任何一次读都能读到某个数据的最近一次写的数据
- 所有进程的顺序一致，不需要和全局时钟下的顺序一致
-
弱一致性
- 最终一致性，随着时间推荐，会最终达到全局一致性
-
举例
- DNS、Gossip都是最终一致性的
- Paxos、Raft、ZAB是强一致性的（不一定，需看情况）
Basic-Paxos
- 角色分类
- Proposer 提案者：可以有多个，用于发起一个议案（由client向Proposer发出），议案包括议案编号、议案内容
- Acceptor 接收者、批准者：用于接收Proposer提出的议案，并决定采纳哪一个议案
- Learner 学习者、记录者：在最终决定采纳某个议案后，进行记录，不做其他事
- 约束条件
- Acceptor必须接受它收到的第一个议案
- Acceptor只认可接收到的最新的议案（即议案编号最新）
- 当某个议案被一半以上Acceptor认可后，那么该议案成功
- 运作流程
Proposer 广播 ---Prepare(n)---> 所有的 Acceptor Proposer <---接受--- Acceptor 1 Proposer <---接受--- Acceptor 2 Proposer <---否认--- Acceptor 3 // 如果有一半以上Acceptor接受，那么该议案成功 // 否则说明还有其他Proposer的议案（编号不同），隔一个随机时间，更新自己的议案编号，重提 Proposer 广播 ---Accpet(n, value)---> 所有的 Acceptor // 议案通过 Proposer <---认可--- 所有的 Acceptor ---认可---> Learner [进行记录]
Multi-Paxos
- 说明
- Basic-Paxos每次都要重新选举一个可信任的Proposer，但实际上Proposer不会随时都挂掉
- 因此，应该先只选举一次可信任的Proposer，后续的议案都由它来发起
- 当该Proposer挂了（没有心跳包），再次进行选举即可
- 该Proposer叫做Leader，Leader只有一个
- 运作流程
// 第一次，需要选举一个 Leader Leader 广播 ---Prepare(n)---> 所有的 Acceptor Leader <---接受--- Acceptor 1 Leader <---接受--- Acceptor 2 Leader <---否认--- Acceptor 3 // 如果有一半以上Acceptor接受，那么选举成功 // 后续一直重复该流程 1 Leader 广播 ---Accpet(n, value)---> 所有的 Acceptor Leader <---认可--- 所有的 Acceptor ---认可---> Learner [进行记录] // 后续一直重复该流程 2 Leader 广播 ---Accpet(n, value)---> 所有的 Acceptor Leader <---认可--- 所有的 Acceptor ---认可---> Learner [进行记录] // 后续一直重复该流程 3 Leader 广播 ---Accpet(n, value)---> 所有的 Acceptor Leader <---认可--- 所有的 Acceptor ---认可---> Learner [进行记录] ...... // 后续一直重复该流程 n ......
Raft
- 代表：copycat
- 说明
- Raft是Multi-Paxos的简化模型
- 区别
- Raft中追加日志的操作必须是连续的（Multi-Paxos中是并发）
- 只有拥有最新、最全日志的节点才能够当选Leader（Multi-Paxos中任意节点都可以写日志，无限制）
- 运作流程
- 同Multi-Paxos
- Leader对应Leader
- Acceptor对应Follower
- 可供参考的动态图
ZAB
- 代表： ZooKeeper
- 基本与Raft相同
- 不同点
- Raft一次leader的任期叫做term，ZAB中叫做epoch
- Raft有leader向follower发送心跳，ZAB相反
- 选主投票方式不同
- 事务操作方式不同
