CAP原理
分布式系统无法同时满足强一致性,可用性和分区容错性,设计中往往需要弱化某个特性的需求
1)一致性: 同一时间访问所有节点得到的数据都是一样的,提交事务时,数据同步到所有的节点后,才算事务提交成功。
2)可用性:系统可以一直处理请求,并在正常时间内处理完
3)分区容错性:出现网络分区故障时,故障的节点不应该影响其他节点提供服务
4)大部分情况下,不会出现网络故障,一旦某个节点出现网络故障:
4.1)牺牲一致性(AP):继续提供服务,故障节点恢复时,再同步数据
4.2)牺牲可用性(CP):拒绝提供服务,直到故障节点恢复
raft共识算法
-
选举过程
1)一开始所有的节点都是follower状态,也就是从节点状态,都被设定一个超时选举时间,这个时间是随机的,一般为150ms至300ms
2)如果从节点在规定的时间内,没有收到来自leader的心跳,它就发起选举:
2.1)将自己的状态切换为候选人状态,并投自己一票
2.2)将任期编号加1,作为自己的任期编号
2.3)向集群的其他从节点发送请求,询问其他从节点是否选举自己为主节点
2.4) 从节点收到选举投票邀请后,如果这个任期内没有投过票,就进行投票,一个节点在一个任期内只能投一票
2.5)当收到来自集群过半的节点投票后,A节点就成为本界任期内的reader,它将周期性发送心跳消息,通知其他节点,我的reader,阻止其他从节点发送新的选举 -
选举结果分析
1)只有一个从节点发起选举:赢得选举后,leader会给所有节点发送消息,避免其他节点触发新的选举
2)两个节点同时发起选举:比如有3个节点A,B,C。A,B同时发起选举,而A的选举消息先到达C,C给A投一票,当B端消息到达C时,在这个任期内,C已经投一票,不能再投给B,A胜出后,会给B,C发心跳消息,节点B发现节点A的term不低于自己的term,知道已经有leader了,于是就转换成follower。
3)没有任何节点获取超过半数的投票,可能是平票的情况。比如加入总共四个节点(A/B/C/D), 节点C和节点D同时成为候选人,节点A投节点C一票,节点B投节点D一票,这就出现了平票的情况,这时候就会等待超时重新选举。如果出现平票的情况,就延长了系统的不可用的时间。