Dledger 技术在消息领域的探索和应用

Photo by Daniel Bowman on Unsplash

一直以来，在多地多中心的消息发送场景下，如何保障数据的完整性和一致性是一个技术难点。本文将和您一起探讨 Dledger 技术，并分享 RocketMQ 的实践。

 

多副本技术的演进

---

1.1 Master/Slave

多副本最早的是Master/Slave架构，即简单地用Slave去同步Master的数据，RocketMQ最早也是这种实现。分为同步模式（Sync Mode）和异步模式（Async Mode），区别就是Master是否等数据同步到Slave之后再返回Client。这两种方式目前在RocketMQ社区广泛使用的版本中都有支持，原理图如下图1所示。

             

             图1 Master-Slave

 

1.2 基于Zookeeper服务

随着 Google 三篇核心技术论文的发表（MapReduce、GFS和BigTable），分布式领域开启了快速发展。在 Hadoop 生态中，诞生了一个基于 Paxos 算法选举 Leader 的分布式协调服务 ZooKeeper。[z1] 由于 ZooKeeper 本身拥有高可用和高可靠的特性，随之诞生了很多基于 ZooKeepe r的高可用高可靠的系统。具体做法如下图2所示：

 图2 Based on Zookeeper/Etcd

如图所示，假如系统里有3个节点，通过ZooKeeper提供的一些接口，可以从3个节点中自动的选出一个Master来。选出一个Master后，另外两个没成功的就自然变成Slave。选完之后，后续过程与传统实现方式中的复制一样。故基于ZooKeeper的系统与基于Master/Slave系统最大的区别就是：选Master的过程由手动选举变成依赖一个第三方的服务（比如ZooKeeper或Etcd）的选举。

基于ZooKeeper的服务还存在一个变种，具体做法如下图3：

图3 Based on ZooKeeper/Etcd

在第一种方式中，发起者（Client）和接收者（Server）都是在同一个进程中的。而在这种方式中Client是脱离于Server之外的，通过Zookeeper，从这三个Client中选出一个Master来，选完Master后把请求同时发送到3个Server里，这样也可以达到多副本的效果。

但是基于ZooKeeper的服务也带来一个比较严重的问题：依赖加重。因为运维ZooKeeper是一件很复杂的事情。

1.3 基于 Raft 服务方式

因为 ZooKeeper 的复杂性，又有了以下 Raft 的方式。Raft 可以认为是 Paxos 的简化版。基于Raft 的方式如下图4所示，与上述两种方式最大的区别是：leader 的选举是由自己完成的。比如一个系统有3个节点，这3个节点的 leader 是利用Raft的算法通过协调选举自己去完成的，选举完成之后，Master 到 Slave 同步的过程仍然与传统方式类似。最大的好处就是去除了依赖，即本身变得很简单，可以自己完成自己的协调。