- 原文链接：https://www.cockroachlabs.com/blog/scaling-raft/
- 原作者：Ben Darnell
- 原文日期：Jun 11, 2015
- 译：zifeiy
在CockroachDB中，我们使用木筏一致算法（Raft consensus algorithm）来确保即使是在及其发生故障的时候，你的数据也保持一致性。
在大多数使用木筏一致算法的数据库系统中——诸如etcd和Consul——这个系统是一个木筏一致群（Raft consesus group）。然而，在CockroachDB中，数据被分到了 范围(ranges) 中，每一个范围都有他自己的一个一致群。
这意味着每一个节点都有可能被分成成百上千的一致群。
这种形式提出了一种挑战，我们通过在顶层引入一层Raft（竹筏）来解决这个问题，我们将顶层的Raft曾作MultiRaft。
在单个范围（range）内，一个节点（node）（是一个，而不是三个或五个）被选举为领导者（leader），它周期性地向他的最随者们发送心跳消息。
当系统增长到包括更多的范围（range）时，处理心跳所需的流量也随之增加。
范围（range）的数量远比节点（node）的数量要多（保持范围的数量较小能够在节点失败的时候帮助提高恢复速度），这些许多的范围又会包含重叠的成员。
这就是引入MultiRaft的原因：
不是让每一个范围单独地运行Raft，而是管理整个节点的值域作为一个整体的组。
每一对节点在每一个时间点上只需要交换一次心跳，而不用考虑节点里面包含了多少个范围。
（译者的理解：每一个节点都将他其中的范围的所有心跳打包后一起发出去）
除了减少心跳网络流量，多阀（MultiRaft）也可以其他领域的效率。
举个例子，多阀仅仅需要少量的，固定数量的goroutines（通常3个），而不用在每一个范围（range）内都部署一个goroutine。
实现和测试一致性算法是一项艰巨的任务，所以我们很高兴能与来自CoreOS的etcd团队紧密合作，而不是重投开始便携这部分的代码。
etcd中的竹筏模拟 是建立在纯净抽象的基础上的，所以我们发现它很容易适应我们的不同寻常的需求，
并且我们已经有能力为etcd和社区做出相应改进。