1. 分布式根本实践
- cap 实践：
consistency：一致性
availablity：可用性
partition tolerance：分区容错
分布式服务在零碎呈现肯定故障的时候，还能够对外提供服务。根本所有分布式系统都能够满足此要求。c 和 a 之间存在矛盾，如果谋求一致性就须要摈弃可用性，如果谋求可用性，数据一致性就不会被满足。
- base 实践：
basic available：根本可用
softstatue：软状态
eventually：最终一致性
零碎能够处于一致性中间状态，但可用，零碎能够达到最终一致性状态，其实现办法能够应用基于消息中间件 + 定时工作补发音讯来实现。
2. 分布式一致性算法
在 cap 实践中，如果保证数据强一致性，就须要所有正本同步主节点的所有数据，在数据同步过程中，对外不可用，在所有分布式一致性算法中，解决此的思维是大多数正本同步（个别都是过半）主节点的数据后，主节点就能够应用对客户端进行相应。
- basic paxos 算法
basic paxos 算法有 prepare、accept 和 learn 三个阶段，以及提案者，决策者和学习者。
prepare 阶段：提案者发出请求到过半的决策者，申请中携带生成的全局惟一递增 id, 该 id 能够是工夫戳 + 机器 id。
accept 阶段：决策者接管到提案者的 id 信息后，通过比拟保留的 id 和申请的 id 大小，如果申请的 id 大于保留的 id，就会把保留中的最大的 id 及对应的提案值作为响应发送给提案者。而且之后决策者会回绝所有 id 小于以后的 id 的提案申请，只承受大于以后 id 的申请。当提案者接管到决策者过半的响应后，就会在所有响应中获取最大 id 的提案值作为提案值，发送给过半决策者，此过半决策者能够与提案决策者不同，决策者收到申请后，就会提交申请。
learn 阶段：所有 learner 同步决策者的数据。具体形式能够是每一个 learner 去申请 accept，也能够所有 learner 抉择一个主 learner，主 learner 同步 accept 的数据，其余 learner 同步主 learner。
上述 paxos 算法是 basic paxos 算法，如果有多个提案者，就会导致活锁问题。为了解决此问题，提出只有一个主提案者，在多个提案者中，先抉择一个主提案者，所有的提案都由该主提案者进行提交。
- Raft 算法
leader 选举
日志同步
-
zab 算法
- 启动选举 leader
每台机器发送 (myid，zxid) 到别的机器，别的机器查看是否是在选举过程中，而后比拟 zxid，投票给 zxid 大的，如果 zxid 雷同就投票给 myid 大的，等到有机器接管到一半以上的投票后即成为 leader
- 启动选举 leader
- 运行中选举
逻辑大抵同启动时选举 leader, 只不过换成 sid 和 zxid，过半投票机制。而后再同步数据。
- kafka 选举
isr 列表
高水位 HW
过半机制