当前位置：首页 > web >正文

DLedger(自动选举)

web 2025/8/13 22:38:29

什么是DLedger

DLedger是一套基于Raft协议的分布式日志存储组件，部署 RocketMQ 时可以根据需要选择使用DLeger来替换原生的副本存储机制解决传统Master-Slave部署架构下的自动故障转移和数据一致性问题

为什么要引入DLedger

在 RocketMQ 4.5 版本之前 RocketMQ 只有 Master/Slave 一种部署方式但是这种方案有问题假如当Master节点挂掉了无法实现自动切换而要人工去重启
为了解决故障转移的问题引入了新的架构
1.利用第三方协调服务集群完成选主，比如 zookeeper 或者 etcd。这种方案会引入了重量级外部组件，加重部署，运维和故障诊断成本，比如在维护 RocketMQ 集群还需要维护 zookeeper 集群，并且 zookeeper 集群故障会影响到 RocketMQ 集群。
2.利用 raft 协议来完成一个自动选主，raft 协议相比前者的优点是不需要引入外部组件，自动选主逻辑集成到各个节点的进程中，节点之间通过通信就可以完成选主。
因此最后选择用 raft 协议来解决这个问题，而 DLedger 就是一个基于 raft 协议的 commitlog 存储库，也是 RocketMQ 实现新的高可用多副本架构的关键。

DLedger 的作用

解决传统Master-Slave部署架构下的自动故障转移和数据一致性问题

设计理念

DLedger 定位

Raft 协议是复制状态机的实现，这种模型应用到消息系统中就会存在问题。对于消息系统来说，它本身是一个中间代理，commitlog 状态是系统最终状态，并不需要状态机再去完成一次状态构建。因此 DLedger 去掉了 raft 协议中状态机的部分，但基于raft协议保证commitlog 是一致的，并且是高可用的。
另一方面 DLedger 又是一个轻量级的 java library。它对外提供的 API 非常简单，append 和 get。Append 向 DLedger 添加数据，并且添加的数据会对应一个递增的索引，而 get 可以根据索引去获得相应的数据。因此 DLedger 是一个 append only 的日志系统。

应用场景

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 存储系统，应用到元信息管理等场景。

设计特点

强一致性
利用Raft算法保证在分布式环境下，所有节点上的日志记录顺序一致

高可用性
通过选举机制，在主节点宕机时可以快速切换新的主节点继续服务

水平扩展
支持增加更多节点以实现更大的存储容量和更高的并发处理能力

无单点故障
每个节点都可以作为备份，任意节点的故障都不会导致整个系统的不可用

DLedger 的优化

性能优化

Raft 协议复制过程

发送消息给 leader，leader 除了本地存储之外，会把消息复制给 follower，然后等待follower 确认，如果得到多数节点确认，该消息就可以被提交，并向客户端返回发送成功的确认。

异步线程模型

DLedger 采用一个异步线程模型，异步线程模型可以减少等待。在一个系统中，如果阻塞点越少，每个线程处理请求时能减少等待，就能更好的利用 CPU，提高吞吐量和性能。
以 DLedger 处理 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 CompletableFuture ，通知通信模块向客户端返回响应。

独立并发的复制过程

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

日志并行复制

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

可靠性优化

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对网络分区的容忍性。