模块化的拆分主要体现在：Raft把一致性协议划分为Leader选举、MemberShip变更、日志复制、Snapshot等几个几乎完全解耦的模块
一句话总结StrongLeader:“你们不要BB!按我说的做，做完了向我汇报!”另外，身为leader必须保持一直BB(heartbeat)的状态，否则就会有别人跳出来想要BB
这里挑重点介绍几个优化点:
单个节点的JRaft-node是没什么实际意义的，下面是三副本的JRaft架构图
单个Raftgroup是无法解决大流量的读写瓶颈的，JRaft自然也要支持multi-raft-group
什么是线性一致读所谓线性一致读，一个简单的例子就是在t1的时刻我们写入了一个值，那么在t1之后，我们一定能读到这个值，不可能读到t1之前的旧值(想想java中的volatile关键字，说白了线性一致读就是在分布式系统中实现javavolatile语义)
如上图ClientA、B、C、D均符合线性一致读，其中D看起来是staleread，其实并不是，D请求横跨了3个阶段，而读可能发生在任意时刻，所以读到1或2都行
重要：接下来的讨论均基于一个大前提，就是业务状态机的实现必须是满足线性一致性的，简单说就是也要具有javavolatile的语义
在JRaft中发起一次线性一致读请求的代码展示：
PD全局的中心总控节点，负责整个集群的调度，不需要自管理的集群可不启用PD(一个PD可管理多个集群，基于clusterId隔离)
Store集群中的一个物理存储节点，一个store包含一个或多个region
Region最小的KV数据单元，每个region都有一个左闭右开的区间[startKey,endKey),可根据请求流量/负载/数据量大小等指标自动分裂以及自动副本搬迁
以上几点(尤其2，3)基本都是依托于JRaft自身的功能来实现，详细介绍请参考JRaft文档
蚂蚁金服中间件团队持续在寻找对于基础中间件（如消息、数据中间件以及分布式计算等）以及下一代高性能面向实时分析的时序数据库等方向充满热情的小伙伴加入，有意者请联系boyan@antfin.com