raft的理解

CAP理论
consist assistance part
一致性 可用性 分区容错性
CAP只能实现两个
根据你的业务需求进行组合
一般用的多的是AP 但是要实现最终的一致性
CP一般在银行转账的时候需要实现强一致性
分区容错是必须要实现的
Nacos可以是AP也可以是CP的，底层有一致性协议层，面向接口编程 看你实现的算法是raft还是阿里的

分布式的共识问题：拜占庭将军问题
raft算法是比paxois更易于理解和实现的算法
可以实现强一致

raft里面的概念：从节点，候选人节点，领导节点 。 三个节点可以升级或者降级
任期：标志最新的领导和之前的领导，说明顺序关系，每选出一个领导会加一

领导的选举：follow节点如果没有受到主节点响应（ping），就升级为候选人，首先给自己投一票，发起投票，任期加一。发起请求让别人都给自己投票，比任期，如果对方的的任期比你新，会让你下课。半数以上则当选，然后给别的节点发送ping信号
票数相同选不出新的leader，然后重新选举，如果候选人没有别的从节点时间短，也会是从节点变成候选人
集群搭建的时候不建议偶数节点，因为平票的情况会比奇数节点多

日志复制：如何保持数据的一致性
数据先不提交 主节点先发送到从节点，发送成功之后再提交

对于集群的常见问题处理原理：脑裂，数据处理的最终一致性问题（考虑所有极端情况）
脑裂：网络分区之后断开链接（脑子裂开） 同时双主节点
根据任期可以把数据重新输入暂停的节点。
少数的中断的节点无法获得半数以上的投票，那么无法成为主节点，恢复之后主节点会让候选人下课

极端情况：主节点宕机
apply通知发送之后leader挂了
领导人完全原则：把上一个领导节点没有完成的给完成了