Raft & Wal in nebula¶

Raft in nebula¶

Multi Raft Group¶

由于 Raft 的日志不允许空洞，几乎所有的实现都会采用 Multi Raft Group 来缓解这个问题，因此 partition 的数目几乎决定了整个 Raft Group 的性能。但这也并不是说 Partition 的数目越多越好：每一个 Raft Group 内部都要存储一系列的状态信息，并且每一个 Raft Group 有自己的 WAL 文件，因此 Partition 数目太多会增加开销。此外，当 Partition 太多时， 如果负载没有足够高，batch 操作是没有意义的。比如，一个有 1w tps 的线上系统单机，它的单机 partition 的数目超过 1w，可能每个 Partition 每秒的 tps 只有 1，这样 batch 操作就失去了意义，还增加了 CPU 开销。 实现 Multi Raft Group 的最关键之处有两点，第一是共享 Transport 层，因为每一个 Raft Group 内部都需要向对应的 peer 发送消息，如果不能共享 Transport 层，连接的开销巨大；第二是线程模型，Mutli Raft Group 一定要共享一组线程池，否则会造成系统的线程数目过多，导致大量的 context switch 开销。

Batch¶

对于每个 Partition 来说，由于串行写 WAL，为了提高吞吐，做 batch 是十分必要的。一般来讲，batch 并没有什么特别的地方，但是 Nebula 利用每个 part 串行的特点，做了一些特殊类型的 WAL，带来了一些工程上的挑战。

举个例子，Nebula 利用 WAL 实现了无锁的 CAS 操作，而每个 CAS 操作需要之前的 WAL 全部 commit 之后才能执行，所以对于一个 batch，如果中间夹杂了几条 CAS 类型的 WAL, 我们还需要把这个 batch 分成粒度更小的几个 group，group 之间保证串行。还有，command 类型的 WAL 需要它后面的 WAL 在其 commit 之后才能执行，所以整个 batch 划分 group 的操作工程实现上比较有特色。

Learner¶

Learner 这个角色的存在主要是为了应对扩容时，新机器需要"追"相当长一段时间的数据，而这段时间有可能会发生意外。如果直接以 follower 的身份开始追数据，就会使得整个集群的 HA 能力下降。 Nebula 里面 learner 的实现就是采用了上面提到的 command wal，leader 在写 wal 时如果碰到 add learner 的 command， 就会将 learner 加入自己的 peers，并把它标记为 learner，这样在统计多数派的时候，就不会算上 learner，但是日志还是会照常发送给它们。当然 learner 也不会主动发起选举。

Transfer Leadership¶

Transfer leadership 这个操作对于 balance 来讲至关重要，当我们把某个 Paritition 从一台机器挪到另一台机器时，首先便会检查 source 是不是 leader，如果是的话，需要先把他挪到另外的 peer 上面；在搬迁数据完毕之后，通常还要把 leader 进行一次 balance，这样每台机器承担的负载也能保证均衡。

实现 transfer leadership， 需要注意的是 leader 放弃自己的 leadership，和 follower 开始进行 leader election 的时机。对于 leader 来讲，当 transfer leadership command 在 commit 的时候，它放弃 leadership；而对于 follower 来讲，当收到此 command 的时候就要开始进行 leader election，这套实现要和 Raft 本身的 leader election 走一套路径，否则很容易出现一些难以处理的 corner case。

Membership change¶

为了避免脑裂，当一个 Raft Group 的成员发生变化时，需要有一个中间状态， 这个状态下 old group 的多数派与 new group 的多数派总是有 overlap，这样就防止了 old group 或者新 group 单方面做出决定，这就是论文中提到的 joint consensus 。为了更加简化，Diego Ongaro 在自己的博士论文中提出每次增减一个 peer 的方式，以保证 old group 的多数派总是与 new group 的多数派有 overlap。Nebula 的实现也采用了这个方式，只不过 add member 与 remove member 的实现有所区别，具体实现方式本文不作讨论，有兴趣的同学可以参考 Raft Part class 里面 addPeer / removePeer 的实现。

Snapshot¶

Snapshot 如何与 Raft 流程结合起来，论文中并没有细讲，但是这一部分我认为是一个 Raft 实现里最容易出错的地方，因为这里会产生大量的 corner case。

举一个例子，当 leader 发送 snapshot 过程中，如果 leader 发生了变化，该怎么办？ 这个时候，有可能 follower 只接到了一半的 snapshot 数据。 所以需要有一个 Partition 数据清理过程，由于多个 Partition 共享一份存储，因此如何清理数据又是一个很麻烦的问题。另外，snapshot 过程中，会产生大量的 IO，为了性能考虑，我们不希望这个过程与正常的 Raft 共用一个 IO threadPool，并且整个过程中，还需要使用大量的内存，如何优化内存的使用，对于性能十分关键。

• 用了两个 IO threadpool，一个专门用于处理 snapshot 的 IO，一个用于处理 event IO。
• 代码中是一个一个 peer 去 send snapshot，避免占用大量内存。