Raft 一致性共识算法—— 开篇
Posted 晚上吃鸡公煲
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Raft 一致性共识算法—— 开篇相关的知识,希望对你有一定的参考价值。
走马上任
你是一名非常靠谱的人才,准备入职 A公司做一名技术总监。
A公司是一家风生水起的创业公司,因行业压力和公司体量巨大,人员流动性非常高,并且项目需求变更和发版速度非常快。
所以经常会有员工做着做着就离职了,手上的项目无以为继,项目中断上线延期,高层对你颇有微词。
怎么办?
招兵买马
问题出现在项目的执行者没有备份,导致的项目风险非常大。
所以你决定招兵买马,通过适当的冗余备份来应对项目风险。
在经过一段时间的招聘之后,你招募了两名得力干将,小智和小障。
现在实施一个项目,你可以将项目细节同时告诉小智和小障,等待他们一起回应确认可以做时,项目就可以按排期进行下去了。
这个时候无论小智还是小障离职,都不会对项目带来风险。
所以现在对风险容错的能力从无,演进到了可以接受一个人离职。
如果公司大环境没有改善,两个人一起离职的可能性也非常高,该怎么办呢?
再招募一个人,大脸猫。
现在实施一个项目,你需要将项目细节同时告诉他们三个人,等待他们一起回应确认再继续进行。
这样对风险容错的能力就提升到了可以接受两个人离职。
由此可见,我们总可以通过增加冗余备份来应对更加极端的风险,但是带来了什么问题呢?
我们在布置项目时,需要等待他们一起确认细节通过,才能确定这个项目到底有没有风险,而一起确认细节通过这个过程可能会非常不稳定,
比如小智和小障一分钟内就可以理解这个项目细节,但是 大脸猫 需要一天,如果在保障允许两人离职的容错条件下,这个时间是必须要等待的。
所以尽管风险控制住了,但是效率大大降低了,许多项目产生了积压,高层对你颇有微词。
怎么办?
快速交付
我们捋一下问题:允许两人离职,目前招募了三个员工,但是部分员工理解项目细节耗时过高,导致整体相应非常慢。
我们可以把问题简单化:理解项目耗时高等同于短暂离职。
既然又是离职问题,我们就又可以通过招人来解决(招更多的人,5个,10个..),但是也可以控制成本不招人,降低允许离职人数的标准。
为了使理解起来更简单,我们先选择后者,而是降低允许离职人数为只能容忍一人离职。
那现在实施项目应该怎么运作呢?
因为团队中有三个人,可以容忍一人离职,也就是同步项目细节的时候,只要有两个人及时回复相应就可以了,第三个人无论是离职还是响应慢,都不会对项目承担风险能力造成损坏,同时又保证了效率。
目前为止,事情进展的很顺利。但是出现了新的问题。
产品经理A要求首页增加一个标签,评审通过你开始布置项目,小智和小障给你响应确保没问题,成功排期,项目顺利实施。
产品经理B要求首页增加一个按钮,评审通过你开始布置项目,大脸猫和小障给你响应确保没问题,成功排期,项目顺利实施。
产品总监觉得首页出现按钮非常怪异决定下线,评审通过你开始布置项目,这时候大脸猫不干了离职了,小障给响应说没问题,他刚做过他了解背景,但是为了应对项目实施中的风险, 你必须要保障至少两个人回应,才能实施项目,大脸猫离职了,那就只能等待小智回复。
但小智之前没有做过,不清楚上下文,只能你再讲一遍上下文,把产品经理B要求首页增加一个按钮这个需求确认同步给小智,小智理解之后,才能继续进行。
但是这个过程你不仅需要和所有人沟通,而且要同步历史,如果需要沟通的人数继续增加为5个人,7个人,问题将更加严峻,也因为这些问题导致你成为了效率的绊脚石,高层对你颇有微词。
怎么办?
这就是一致性共识
照旧捋一下问题,你需要满足高可用和高效,招聘了一个团队。
但是又希望团队自治,队员自驱动,一件事情你只需要告诉一个队员就行,他会帮助你去落实,而不在乎团队规模有多大。
怎样选出这个负责人呢,选举的过程怎样保证自动自发呢,选举后你交代的事情怎么样保证同步呢,如何保证这些过程不会出错呢?等等等
如何去解决这些问题,这就是一致性共识要实现的事情。
在接下来的文章中,我会用故事+原理+代码实现的方式,为你讲明白Raft 一致性共识算法
涉及的主要篇章有
复制状态机
领导者选举
日志复制
安全保证
从节点故障
数据持久化
时序和可用性
领导者变更
集群角色变更
日志压缩
客户端交互
以上是关于Raft 一致性共识算法—— 开篇的主要内容,如果未能解决你的问题,请参考以下文章