Apache Ratis中的multi-raft实现原理

前言


在之前笔者写过一篇关于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多了,自然它所能允许处理的最大的请求量上限也自然提高了。

OK,以上就是本文对Apache Ratis multi-raft功能的简单阐述了。

引用


[1].https://issues.apache.org/jira/browse/RATIS-91

©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值