Raft
文章目录
分布式一致性算法
问题
- 为什么需要分布式一致性算法?
- raft 是如何工作的?
案例
你接到一个需求,需要做一个人大代表投票系统,用户通过前端页面对候选人进行投票,在后端服务内存中记录每个候选人的票数,投票结束后将数据最终结果提供给领导,由领导宣布最终结果.
你接到需求后马上就开始做了,每次收到前端的请求,对相应候选人的票数在内存中加 1,在内部试用的时候,大家开始疯狂投票,投票结束后你将数据提供给领导,领导和内部投票结果一对比发现你这个系统中部分人的票数不对,偏低;你绞尽脑汁排查问题,最后发现是多线程并发没有加锁导致,问题修复后,开始内部测试,没有任何问题.
领导说既然这样我们就先在一个学校试下,在学生投票的时候,中午还可以投票,但是下午就提示服务无法访问,领导大怒,你做的这个系统是个锤子啊,都用不了;你赶快看了下,原来是部署程序的机器网卡坏了,你很无奈,这明显不是我的问题啊,我能有什么办法,但是看着领导的脸色,你赶快开始想解决方案.你想了下,既然一台不行,我就多部署几台不就好了,不过你又想这个投票数据都是在内存中,部署多台机器如何保证数据的一致性呢?
最后你看到了 raft 算法,有强一致性,而且有容错性,在部分机器坏的情况下,也能够让系统正常使用,你在 github 上找了现成的实现,然后导入到自己的系统中,修改完成后,你开了 5 台机器,然后高兴的告诉领导,这次绝对没问题领导勉强在信你一次,在学校再次尝试发现没有问题,然后将让几个省份开始尝试,你看到服务在不断的收到请求,你非常担心服务会挂掉,如果服务挂了,那么怕是就要被辞退了,你看着自己的 5 台服务,突然有一台变为不可用,但是按照 raft 算法 5 台中可以容忍 2 台不可用,你立马开了新的服务器,然后对自己的服务进行迁移,添加新的节点,去除有问题的节点,在过程中系统完全可用,就这样所有的人都投完票,你将结果导出给领导,领导很满意,你从此走向人生巅峰.
关键点
- 进程内可以通过锁来保证数据的一致性
- 分布式系统就需要通过一致性算法来保证
原理
角色
- leader: 领导人
- candidate: 候选人
- follower: 追随者
说明
- 在每一期选举中每个节点只有一票
- candidate 都会将票投给自己
- 在刚开始没有 leader 的时,每个节点超时时间不同,谁先超时就开始发起选举
- candidate 获取的票数大于当前节点总数的一半,则变为 leader
- 如果多个 candidate 获取的票数相同,则需要开始下轮选举
- 如果 candidate 收到投票请求,且对方的任期比自己的大的时候,就变为追随者
结论
- 分布式系统可以提高系统的容错性,但是同时也会带来数据不一致的问题,而分布式一致性算法主要解决这个问题
- raft 中数据都是有 leader 来同步,且保证了强一致性
拓展
- 强一致性
- 弱一致性
- 最终一致性
- 分布式事务
文章作者 Ward Harris
上次更新 2019-10-20