前言

在之前笔者写过一篇关于Ozone利用Apache Ratis multi-raft功能来提升其系统的throughput的文章（Ozone Multi-Raft机制对于更大throughput处理量的支持），不过那篇博文只是简单介绍了下在multi-raft的支持下，一个Ozone Datanode节点可以允许成为多个Pipeline的一员,从而达到加大Ozone请求处理量的目的。本文笔者来聊聊Apache Ratis multi-raft的具体实现原理，聊聊从multi-raft的应用到本质。

Single-Raft模式

既然我们有multi-raft模式，那也就是说还有对应的single-raft模式。这里说的Single-raft模式其实是最早RaftServer实现的模式，一个节点上面只启动一个RaftServer实例，它的正常server state无非两种Leader或者Follower（假设不考虑投票选举阶段）。

对应一个单节点单RaftServer实例而言，它在本地节点上以及服务自身会存有以下一些必要的信息：

StateMachine，内部状态机。
RaftLog，持久化在本年底的transaction log。
还有Snapshot数据

其中RaftLog和Snapshot的数据是落在本地节点盘之上的。

下图是RaftServer内部服务的一个简要模型图：
在这里插入图片描述
上面括号中的F为Follower，SM为StateMachine的意思。对Lead/Follower RaftServer之间交互通信感兴趣的同学可阅读笔者之前写的相关文章：Apache Ratis的Ratis Server主从同步机制。

那么问题来了，在multi-raft模式下，上图中这个结构会变成什么样呢？

Multi-raft改进

Apache Ratis社区在JIRA RATIS-91: Add multi-raft support实现了这个功能。在这个功能下，它主要做了这么几个事情：

新增接口允许client端向service端添加新的raft group，一个新的raft group可理解为一组新的Leader/Follower RaftServer服务。
分离出RaftServerProxy和RaftServer服务，一个节点可以启动多个RaftServer实例，按照raft group id区别开，RaftServer有其独立的StateMachine以及其对应存储RaftLog的位置。
RaftClient进行请求通信时需要带上raft group id，以此让server Proxy知道请求应定向到哪个具体的RaftServer中去。

新的mult-raft RaftServer结构类似如下：

在这里插入图片描述
对比上图和上上图，同样是3个节点，single-raft模式只能构造出1组RaftServer服务，而multi-raft可以构造出多组以上，这取决于用户实际使用场景怎么使用设置，也不是越多越好。因为一个节点所包含的RaftServer多了，自然它所能允许处理的最大的请求量上限也自然提高了。