什么是 MultiRaft ？

什么是 MultiRaft

这里引用 Cockroach ( MultiRaft 的先驱，出来的比 TiDB 早 )对 MultiRaft 的定义：

In CockroachDB, we use the Raft consensus algorithm to ensure that your data remains consistent even when machines fail. In most systems that use Raft, such as etcd and Consul, the entire system is one Raft consensus group. In CockroachDB, however, the data is divided into ranges, each with its own consensus group. This means that each node may be participating in hundreds of thousands of consensus groups. This presents some unique challenges, which we have addressed by introducing a layer on top of Raft that we call MultiRaft.

在 CockroachDB 中，我们使用 Raft 一致性算法来确保在机器发生故障时数据也能保持一致。在大多数使用 Raft 的系统中，如 etcd 和 Consul，整个系统只有一个 Raft 共识组。然而，在 CockroachDB 中，数据被分成不同的范围，每个范围都有自己的共识组。这意味着每个节点都可能参与成千上万个共识组。这就提出了一些独特的挑战，我们通过在 Raft 之上引入一层 MultiRaft 来解决这些问题。

简单来说，MultiRaft 是在整个系统中，把所管理的数据按照一定的方式切片，每一个切片的数据都有自己的副本，这些副本之间的数据使用 Raft 来保证数据的一致性，在全局来看整个系统中同时存在多个 Raft-Group，就像这个样子：

 

 

MultiRaft 需要解决的问题

单个 Raft-Group 在 KV 的场景下存在一些弊端:

(1) 系统的存储容量受制于单机的存储容量（使用分布式存储除外）。

(2) 系统的性能受制于单机的性能（读写请求都由Leader节点处理）。

 

MultiRaft 需要解决的一些核心问题：

(1) 数据何如分片。

(2) 分片中的数据越来越大，需要分裂产生更多的分片，组成更多 Raft-Group。

(3) 分片的调度，让负载在系统中更平均（分片副本的迁移，补全，Leader 切换等等）。

(4) 一个节点上，所有的 Raft-Group 复用链接（否则 Raft 副本之间两两建链，链接爆炸了）。

(5) 如何处理 stale 的请求（例如 Proposal 和 Apply 的时候，当前的副本不是 Leader、分裂了、被销毁了等等）。

(6) Snapshot 如何管理（限制Snapshot，避免带宽、CPU、IO资源被过度占用）。

要实现一个 Multi-Raft 还是很复杂和很有挑战的一件事情。

 

Raft论文翻译：https://blog.csdn.net/qq_38289815/article/details/104314348

转载自：https://my.oschina.net/u/2244142/blog/1609103