分布式学习笔记

本文介绍了CAP原理,即在分布式系统中,一致性、可用性和分区容错性三者不能同时满足。着重讨论了在面对网络故障时,如何通过牺牲一致性(AP)或可用性(CP)来保证服务。同时,详细解析了raft共识算法的选举过程,包括节点状态转换和平票情况下的处理。
摘要由CSDN通过智能技术生成

CAP原理

分布式系统无法同时满足强一致性,可用性和分区容错性,设计中往往需要弱化某个特性的需求
1)一致性: 同一时间访问所有节点得到的数据都是一样的,提交事务时,数据同步到所有的节点后,才算事务提交成功。
2)可用性:系统可以一直处理请求,并在正常时间内处理完
3)分区容错性:出现网络分区故障时,故障的节点不应该影响其他节点提供服务
4)大部分情况下,不会出现网络故障,一旦某个节点出现网络故障:
4.1)牺牲一致性(AP):继续提供服务,故障节点恢复时,再同步数据
4.2)牺牲可用性(CP):拒绝提供服务,直到故障节点恢复

raft共识算法

  1. 选举过程
    1)一开始所有的节点都是follower状态,也就是从节点状态,都被设定一个超时选举时间,这个时间是随机的,一般为150ms至300ms
    2)如果从节点在规定的时间内,没有收到来自leader的心跳,它就发起选举:
    2.1)将自己的状态切换为候选人状态,并投自己一票
    2.2)将任期编号加1,作为自己的任期编号
    2.3)向集群的其他从节点发送请求,询问其他从节点是否选举自己为主节点
    2.4) 从节点收到选举投票邀请后,如果这个任期内没有投过票,就进行投票,一个节点在一个任期内只能投一票
    2.5)当收到来自集群过半的节点投票后,A节点就成为本界任期内的reader,它将周期性发送心跳消息,通知其他节点,我的reader,阻止其他从节点发送新的选举

  2. 选举结果分析
    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一票,这就出现了平票的情况,这时候就会等待超时重新选举。如果出现平票的情况,就延长了系统的不可用的时间。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值