走马上任

你是一名非常靠谱的人才，准备入职 A公司做一名技术总监。

A公司是一家风生水起的创业公司，因行业压力和公司体量巨大，人员流动性非常高，并且项目需求变更和发版速度非常快。

所以经常会有员工做着做着就离职了，手上的项目无以为继，项目中断上线延期，高层对你颇有微词。

怎么办？

招兵买马

问题出现在项目的执行者没有备份，导致的项目风险非常大。

所以你决定招兵买马，通过适当的冗余备份来应对项目风险。

在经过一段时间的招聘之后，你招募了两名得力干将，小智和小障。

现在实施一个项目，你可以将项目细节同时告诉小智和小障，等待他们一起回应确认可以做时，项目就可以按排期进行下去了。

这个时候无论小智还是小障离职，都不会对项目带来风险。

所以现在对风险容错的能力从无，演进到了可以接受一个人离职。

如果公司大环境没有改善，两个人一起离职的可能性也非常高，该怎么办呢？

再招募一个人，大脸猫。

现在实施一个项目，你需要将项目细节同时告诉他们三个人，等待他们一起回应确认再继续进行。

这样对风险容错的能力就提升到了可以接受两个人离职。

由此可见，我们总可以通过增加冗余备份来应对更加极端的风险，但是带来了什么问题呢？

我们在布置项目时，需要等待他们一起确认细节通过，才能确定这个项目到底有没有风险，而一起确认细节通过这个过程可能会非常不稳定，

比如小智和小障一分钟内就可以理解这个项目细节，但是 大脸猫 需要一天，如果在保障允许两人离职的容错条件下，这个时间是必须要等待的。

所以尽管风险控制住了，但是效率大大降低了，许多项目产生了积压，高层对你颇有微词。

怎么办？

快速交付

我们捋一下问题：允许两人离职，目前招募了三个员工，但是部分员工理解项目细节耗时过高，导致整体相应非常慢。

我们可以把问题简单化：理解项目耗时高等同于短暂离职。

既然又是离职问题，我们就又可以通过招人来解决（招更多的人，5个，10个..），但是也可以控制成本不招人，降低允许离职人数的标准。

为了使理解起来更简单，我们先选择后者，而是降低允许离职人数为只能容忍一人离职。

那现在实施项目应该怎么运作呢？

因为团队中有三个人，可以容忍一人离职，也就是同步项目细节的时候，只要有两个人及时回复相应就可以了，第三个人无论是离职还是响应慢，都不会对项目承担风险能力造成损坏，同时又保证了效率。

目前为止，事情进展的很顺利。但是出现了新的问题。

产品经理A要求首页增加一个标签，评审通过你开始布置项目，小智和小障给你响应确保没问题，成功排期，项目顺利实施。

产品经理B要求首页增加一个按钮，评审通过你开始布置项目，大脸猫和小障给你响应确保没问题，成功排期，项目顺利实施。

产品总监觉得首页出现按钮非常怪异决定下线，评审通过你开始布置项目，这时候大脸猫不干了离职了，小障给响应说没问题，他刚做过他了解背景，但是为了应对项目实施中的风险， 你必须要保障至少两个人回应，才能实施项目，大脸猫离职了，那就只能等待小智回复。

但小智之前没有做过，不清楚上下文，只能你再讲一遍上下文，把产品经理B要求首页增加一个按钮这个需求确认同步给小智，小智理解之后，才能继续进行。

但是这个过程你不仅需要和所有人沟通，而且要同步历史，如果需要沟通的人数继续增加为5个人，7个人，问题将更加严峻，也因为这些问题导致你成为了效率的绊脚石，高层对你颇有微词。

怎么办？

这就是一致性共识

照旧捋一下问题，你需要满足高可用和高效，招聘了一个团队。

但是又希望团队自治，队员自驱动，一件事情你只需要告诉一个队员就行，他会帮助你去落实，而不在乎团队规模有多大。

怎样选出这个负责人呢，选举的过程怎样保证自动自发呢，选举后你交代的事情怎么样保证同步呢，如何保证这些过程不会出错呢？等等等

如何去解决这些问题，这就是一致性共识要实现的事情。

在接下来的文章中，我会用故事+原理+代码实现的方式，为你讲明白Raft 一致性共识算法

涉及的主要篇章有

• 复制状态机

• 领导者选举

• 日志复制

• 安全保证

• 从节点故障

• 数据持久化

• 时序和可用性

• 领导者变更

• 集群角色变更

• 日志压缩

• 客户端交互