在RocketMQ 4.5版本之前，RocketMQ只有Master/Slave一种部署方式，虽然这种模式可以提供一定的高可用性但也存在比较大的缺陷。为了实现新的高可用多副本架构，RockeMQ最终选用了基于Raft协议的commitlog存储库DLedger。

一、DLedger引入目的

在RocketMQ 4.5版本之前，RocketMQ只有Master/Slave一种部署方式，一组Broker中有一个Master，有零到多个Slave，Slave通过同步复制或异步复制方式去同步Master的数据。Master/Slave部署模式，提供了一定的高可用性。

但这样的部署模式有一定缺陷。比如故障转移方面，如果主节点挂了还需要人为手动的进行重启或者切换，无法自动将一个从节点转换为主节点。因此，我们希望能有一个新的多副本架构，去解决这个问题。

新的多副本架构首先需要解决自动故障转移的问题，本质上来说是自动选主的问题。这个问题的解决方案基本可以分为两种：

利用第三方协调服务集群完成选主，比如zookeeper或者etcd。这种方案会引入了重量级外部组件，加重部署，运维和故障诊断成本，比如在维护RocketMQ集群还需要维护zookeeper集群，并且 zookeeper 集群故障会影响到 RocketMQ集群。

利用raft协议来完成一个自动选主，raft协议相比前者的优点，是它不需要引入外部组件，自动选主逻辑集成到各个节点的进程中，节点之间通过通信就可以完成选主。

因此最后选择用raft协议来解决这个问题，而DLedger就是一个基于raft协议的commitlog存储库，也是RocketMQ实现新的高可用多副本架构的关键。

二、DLedger 设计理念

1、DLedger的定位

raft协议是复制状态机的实现，这种模型应用到消息系统中就会存在问题。对于消息系统来说，它本身是一个中间代理，commitlog的状态是系统最终的状态，并不需要状态机再去完成一次状态的构建。因此DLedger去掉了raft协议中状态机的部分，但基于raft协议保证commitlog是一致的，并且是高可用的。

另一方面DLedger它又是一个轻量级的java library。它对外提供的API非常简单，append和get。Append向Dledger添加数据，并且添加的数据会对应一个递增的索引，而get API可以根据索引去获得相应的数据。所以DLedger是一个append only的日志系统。

2、DLedger的应用场景

DLedger的其中一个应用就是在分布式消息系统中，RocketMQ 4.5版本发布后，可以采用RocketMQ on DLedger方式进行部署。

DLedger commitlog代替了原来的commitlog，使得commitlog拥有了选举复制能力，然后通过角色透传的方式，raft角色透传给外部broker角色，leader对应原来的Master，follower和candidate对应原来的Slave。

因此RocketMQ的broker拥有了自动故障转移的能力，如果在一组broker中，一个Master挂了以后，依靠DLedger自动选主的能力，会重新选出leader，然后通过角色透传变成新的Master。

DLedger还可以构建高可用的嵌入式KV存储。我们把对一些数据的操作记录到DLedger中，然后根据数据量或者实际需求，恢复到hashmap或者rocksDB，从而构建一致的，高可用的KV存储系统，应用到元信息管理等场景。

三、DLedger的优化

1、性能优化

Raft协议复制过程可以分为四步，先是发送消息给leader，leader除了本地存储之外，会把消息复制给follower，然后等待follower确认，如果得到多数节点确认，该消息就可以被提交，并向客户端返回发送成功的确认。DLedger中如何去优化这一复制过程？

（1）异步的线程模型

DLedger采用一个异步线程模型，异步的线程模型可以减少等待。在一个系统中，如果阻塞点越少，每个线程处理请求时能减少等待，就能更好的利用CPU，提高吞吐量和性能。

以DLedger Server处理Append请求的整个过程来讲述DLedger异步线程模型。图中粗箭头表示RPC请求，实现箭头表示数据流，虚线表示控制流。

首先客户端发送Append请求，由Dledger的通信模块处理，当前DLedger默认的通信模块是利用Netty实现的，因此Netty IO线程会把请求交给业务线程池中的线程进行处理，然后IO线程直接返回，处理下一个请求。业务处理线程处理Append请求有三个步骤：

首先是把Append数据写入自己日志中，也就是pagecache中。

然后生成Append CompletableFuture ，放入一个Pending Map中，由于该日志还没有得到多数的确认，所以它是一个判定状态。

第三步唤醒EnrtyDispatcher线程，通知该线程去向follower复制日志。

三步完成以后业务线程就可以去处理下一个Append请求，中间几乎没有任何等待。

另一方面，复制线程EntryDispatcher会向follower复制日志，每一个follower都对应一个EntryDispatcher线程，该线程去记录自己对应follower的复制位点，每次位点移动后都会去通知QurumAckChecker线程，这个线程会根据复制位点的情况，判断是否一条日志已经复制到了多数节点上，如果已经被复制到了大多数的节点，该日志就可以被提交，并去完成对应的Append，通知通信模块向客户端返回响应。

（2）独立并发的复制过程

在DLedger中，leader 向所有 follower 发送日志也是完全相互独立和并发的，leader为每个follower分配一个线程去复制日志，并记录相应的复制的位点，然后再由一个单独的异步线程根据位点情况检测日志是否被复制到了多数节点上，返回给客户端响应。

（3）日志并行复制

传统的线性复制是leader向follower复制日志，follower确认后下一个日志条目再复制，也就是leader要等待follower对前一条日志确认后才能复制下一条日志。

这样的复制方式保证了顺序性，且不会出错，但吞吐量很低，时延也比较高，因此DLedger设计并实现日志并行复制的方案，不再需要等待前一个日志复制完成再复制下一个日志，只需在follower中维护一个按照日志索引排序请求列表，follower线程按照索引顺序串行处理这些复制请求，对于并行复制后可能出现数据缺失问题，可以通过少量数据重传解决。

2.可靠性优化

（1）DLedger对网络分区的优化

如果出现上图的网络分区，n2与集群中的其他节点发生了网络隔离，按照raft论文实现，n2会一直请求投票，但得不到多数的投票，term一直增大。一旦网络恢复后，n2就会去打断正在正常复制的n1和n3，进行重新选举。

为了解决这种情况，DLedger的实现改进了raft协议，请求投票的过程分成了多个阶段，其中有两个重要阶段：WAIT_TO_REVOTE和WAIT_TO_VOTE_NEXT。

WAIT_TO_REVOTE是初始状态，这个状态请求投票时不会增加term。

WAIT_TO_VOTE_NEXT则会在下一轮请求投票开始前增加term。

对于图中n2情况，当有效的投票数量没有达到多数量时。可以将节点状态设置WAIT_TO_REVOTE，term不会增加。通过这个方法，提高了Dledger对网络分区的容忍性。

（2）DLedger可靠性测试

DLedger还有非常高的容错性。它可以容忍各种各样原因导致节点无法正常工作，比如：

进程异常崩溃
机器节点异常崩溃（机器断电，操作系统崩溃）
慢节点（出现Full GC，OOM等）
网络故障，各种各样的网络分区

为了验证Dledger对这些故障的容忍性，除了本地对DLedger进行了各种各样的测试，还利用分布式系统验证与故障注入框架Jepsen来检测存在的问题，并验证系统的可靠性。

Jepsen框架主要是在特定故障下验证系统是否满足一致性。Jepsen 验证系统由 6 个节点组成，一个控制节点（Control Node），五个DB 节点（DB Node）。

控制节点可以通过SSH登录到DB节点，通过控制节点的控制，可以在DB节点完成分布式系统的下载，部署，组成一个待测试的集群。测试开始后，控制节点会创建一组Worker进程，每一个Worker都有自己的分布式系统客户端。

Generator产生每个客户端执行的操作，客户端进程将操作应用于待测试的分布式系统。每个操作的开始和结束以及操作结果记录在历史记录中。

同时，一个特殊的Client进程Nemesis将故障引入系统。测试结束后，Checker分析历史记录是否正确，是否符合一致性。

根据DLedger的定位，它是一个基于raft协议的commitlog存储库，是一个Append only的日志系统，采用Jepsen的Set模型进行测试。

Set模型的测试流程分为两个阶段。第一阶段由不同的客户端并发地向待测试集群添加不同的数据，中间会进行故障注入。第二阶段，向待测试集群进行一次最终读取，获得读取的结果集。最后验证每一个成功添加的元素都在最终结果集中，并且最终的结果集也仅包含企图添加的元素。

上图是DLedger其中一次测试结果，有30个客户端进程并发地向待测试的DLedger集群添加数据，中间会引入随机对称网络分区，故障引入的间隔时间默认是30s，也就是30s正常运行，30s的故障引入，再30s正常运行、30s故障引入，一直循环。整个阶段一共持续600s。可以看到最后一共发送了16万个数据，中间没有出现数据丢失，lost-count=0，也没有出现不应该存在的数据，uexpected-count=0，一致性测试通过。

上图展示了该次测试中客户端对DLedger集群每一次操作情况，蓝色小框表示添加成功，红色小框表示添加失败，黄色小框表示不确定是否添加成功（比如多数认证超时），图中灰色部分表示故障引入的时间段。

可以看出一些故障引入时间段造成集群短暂的不可用，一些故障时间段则没有，这是合理的。因为是随机网络隔离，所以需要看隔离的节点会不会造成集群重新选举。但即使造成集群重新选举，一段时间后，DLedger集群也会恢复可用性。

除了测试对称网络分区故障，还测试了其他故障下Dledger的表现情况，包括随机杀死节点，随机暂停一些节点的进程模拟慢节点的状况，以及bridge、partition-majorities-ring等复杂的非对称网络分区。在这些故障下，DLedger都保证了一致性，验证了DLedger有很好可靠性。

四、DLedger的未来发展

DLedger接下来的计划包括:

Leader节点优先选择
RocketMQ on DLedger Jepsen 测试
运行时成员变更
增加观察者（只参与复制，不参与投票）
构建高可用的K/V存储
……

DLedger现在是在OpenMessaging下的一个项目，欢迎社区的同学一起加入，来构建高可用高性能的commitlog存储库。

作者介绍：

金融通：2018年中间件性能挑战赛优胜奖，RocketMQ源码爱好者、RocketMQ Contributor。

武文良：SnoWalker，中间件发烧友，RocketMQ北京社区联合发起人之一，社区布道师。专注于后端分布式领域，对分布式架构、中间件原理、Devops有着较为深刻的认识和丰富的实践经验。

创作场景

RocketMQ 实现高可用多副本架构的关键：基于 Raft 协议的 commitlog 存储库 DLedger