算法：Raft
对象：
复制状态机集群
主要问题：
保证一个状态机集群里面的机子一致性良好
两个关键问题：
1. 没有 Master 时需要选举出下一个 Master，且要保证同时只有一个 Master
2. 机器重连后的 log（状态机命令序列） 同步
解决方案：
问题 1 的解决方案：
-
集群的数量(sum) 必须是大于 1 的奇数。
-
每个机器都启动一个定时器，当一定时间内没有收到来自 Leader 的消息，则视为 Leader 已不可用，从 Follower 转换成 Candidate，准备选举 Leader。
-
选举过程中，每个机器只可选一个 Candidate，而且必须得到大于 sum/2 个投票才可当选为 Leader。
-
当同时有两个 Candidate 竞选 Leader 时，有可能每个 Candidate 都拿不到多数选票，因为选举也有 timeout，而且是一定范围的随机，所以只要出现多个 Candidate，就简单的重置定时器而已。性能不一定最高，但简单且健壮。
问题 2 的解决方案
-
对于一个集群来说，每次从无 Leader 到进行选举是一个阶段(Term)，所以在旧阶段失联的机器重连后，判断当前集群所在的阶段，若已落后，则无条件用 Leader 的 log 覆盖自己的，成为一个 Follower。
-
所以在 Raft 中，只有 Leader 向 Follower 发送 log，这简化了复制过程，但在某些条件下，系统的复制性能会下降。
-
对于每个客户端请求，只有在超过半数机器复制成功(log 写入成功)时，才能向客户端响应成功。
-
同样在选举时，log 数量多的 Candidate 拥有更高的权重。
解决一致性的开源解决方案Zookeeper
基于Raft算法的基础服务，相当于TCP/IP下面的下层协议，为上层的应用提供服务。
基础服务目标：提供基础的文件服务
基础服务Zookeeper 可以看做提供了一个分布式且保证了操作一致性的文件系统，其设计目标不是像 GFS 一样管理大量大文件，而是以文件系统的目录和文件作为基本数据结构，提供一系列 API，方便用户构建自己的分布式服务。
两阶段提交：多个集群的分布式实务算法
用处
保证一个集群实务的原子性。
两步提交
- 预提交，让协调者给参与者，让参与者预执行。
- 通过预执行的结果反馈，协调者来判断参与者们是否需要全部commit：如果结果反馈全部为OK，那么就commit上去。如果参与者结果反馈有一个不行，那就让协调者
多个集群在 并发 和 一致性 之间的平衡
算法：OOC 乐观并发控制
背景：有很多集群的操作不是互斥的。比如A集群进行操作A1，B集群进行操作B1，然而A和B操作不影响整个系统的一致性。
上面的两阶段提交过程：
参与者预执行->把结果发给协调者->协调者协调（需要等待所有节点）->发送协调结果给所有节点->所有节点统一进行提交/回滚。
现在的提交过程：
参与者预执行->结果发给协调者->协调者判定是否和其他集群操作冲突->协调者发结果参与者->
网友评论