滴滴出行消息队列团队近日开源了其内部广泛使用的分布式消息中间件产品 DDMQ，这是一款致力于提供低延迟、高并发、高可用、高可靠消息服务的企业级消息队列产品。 DDMQ已经在滴滴内部稳定运行了两年多时间，支撑了网约车、小桔车服、地图、金融、智能驾驶、智慧交通、外卖等业务的稳定运行。日消息流水达到千亿级别，整体服务可用性超过5个9。本文将从从产品特性、适用场景和架构设计等方面对 DDMQ 进行较为详细的介绍。

产品特性

DDMQ 具有如下的优秀特性：

低延迟高吞吐：毫秒级延迟，单机百万条消息吞吐。
丰富的消息类型：具备实时消息、延时消息和分布式事务消息。
海量消息存储，支持消息回溯消费：支持 RocketMQ 和 Kafka 作为实时消息的存储引擎，使用RocksDB 作为延时消息的存储引擎。
秒级延时消息：支持单条消息设置精确到秒级的延迟时间，提供普通延时消息和循环延时消息。
多语言客户端，提供了主流开发语言SDK，包括PHP, Java, Go, C/C++, Python，在API 上保持着最易使用的 High Level 形式。
多种消费方式：支持通过 Thrift RPC拉取、HTTP 推送和第三方存储直写的方式消费消息。
支持灵活的消息过滤和转换功能：通过使用 Groovy 脚本在服务端进行消息体的转换和过滤，能做有效减少客户端和服务器的数据传输量，减轻客户端处理消息的负载。
统一的Web控制台：方便用户管理Topic等资源，通过控制台可以实现配置生产和消费的限流值、消费方式、Groovy脚本、启停消费、重置消费进度等功能。
完善的监控配套：提供模块的健康检查和消息堆积告警功能。

适用场景

消息队列作为构建现代分布式应用所必备的基础设施，有着广泛的应用场景。

削峰填谷

在秒杀等场景下会导致短时间流量的暴涨，下游系统会因为缺少保护而过载甚至崩溃。DDMQ提供的海量堆积能力和消费限流能够确保下游系统的平稳运行。

异步解耦
- 通过上下游系统的松耦合设计，可以保证上游系统不会因为下游系统的宕机而不可用。确保主流程的正常稳定运行。
顺序消息
- 现实中需要保证顺序的场景很多，比如订单系统中订单创建、支付、退款等流程，均需要保证顺序。 DDMQ提供的顺序消费功能可以保证消息的先进先出。
事务消息
- 在微服务的场景下，通过DDMQ的事务消息能够达到分布式事务的最终一致性。

整体架构设计

下面这张图描述了DDMQ 的总体架构。主要包括 Broker Cluster、Producer Proxy Cluster（以下简称 PProxy），Consumer Proxy Cluster（以下简称CProxy），SDK，Console 等模块。

Broker Cluster 是DDMQ的消息存储层。使用 RocketMQ作为实时消息的存储引擎（同时也支持使用Kafka），Chronos则是我们基于 RocksDB自研的延时消息存储引擎。

PProxy 是DDMQ的生产代理服务, 内置 Thrift RPC Server，生产 SDK 通过RPC 调用将消息发送给 PProxy，然后再由PProxy负责将消息生产到具体的 Broker 中去，在 PProxy 中我们实现了生产限流、重试和消息批量生产等功能。

CProxy 是DDMQ的消费代理服务，也内置了Thrift RPC Server，当选择SDK消费时，消费方以 pull 的方式从 CProxy 中拉取消息，由于 CProxy 中的PullBuffer提前缓存了一定数量的待消费消息，因此消费的延迟很低。如果选择HTTP方式消费，则直接由CProxy将消息推送到业务指定的回调URL地址。在CProxy 中，我们实现了消息过滤（通过编写Groovy脚本）、消息体转换（Transit）、重试、消费限流、顺序消费内部排序等功能。

Console是DDMQ的控制台，用户通过控制台申请Topic、Group等资源。Topic等数据会持久化到MySQL并推送到 Zookeeper；PProxy和CProxy通过读取、监听 Zookeeper 上的Topic和Group 数据来实时控制消息的生产和消费逻辑。

DDMQ选择Proxy+SDK的架构，主要有这几个好处：

方便多语言SDK的实现，由于滴滴内部使用的技术栈比较多，将主要逻辑放在 Proxy 上有利于降低 SDK的复杂度，让SDK的开发速度大大加快。目前在滴滴内部支持PHP, Go , C/C++, Java, Python, Node.js等语言的SDK实现。
存储层业务无感知，由于Proxy层屏蔽了后面的RocketMQ或Kafka，使得存储层的切换可以做到业务无感知。
加快新功能迭代速度，新功能的开发都在 Proxy 层实现，降低了SDK的升级频率。

延迟队列的设计

在开源版本的 RocketMQ 里提供了多种固定延迟 level 的延时消息支持，可以发送几个固定的延时时间的延时消息，比如延时 10s, 30s…，但是这种不同延时 level 的延时消息并不能满足滴滴内部众多业务方的需求，我们需要的是任意时间精度的延时。因次我们基于 RocksDB 自研了延时消息队列Chronos，以DDMQ子模块的形式对外提供服务。

上面这张图描述了 Chronos 的总体结构；简单来说，生产 SDK 通过 PProxy 提供的 sendDelay RPC 将延时消息发送到 PProxy，然后由 PProxy 将消息生产到 Chronos 固定的内部 topic 上（chronos_inner_xxx）。Chronos模块再去消费 inner topic 的消息并将消息存储到本地的 RocksDB 里去。基于本地内置的 RocksDB 存储引擎构造一个时间轮服务，会将到期的消息再发送给PProxy，以供业务方消费或HTTP推送给业务方。

对RocketMQ 的扩展改造 --（broker 自动主从切换）

熟悉RocketMQ的同学应该知道，目前开源版本的RocketMQ broker 是没有主从自动切换的。如果Master挂了，那就写不进去了。然后Slave只能提供只读的功能。当然如果你的topic在多个主节点上都创建了，虽然不会完全写不进去，但是对单分片顺序消费的场景，还是会产生影响。所以我们就自己加了一套主从自动切换的功能。

结合RocketMQ现有的结构，可以采用如上结构，探活采用多个节点同时向master发送探测消息的方式，相对心跳方式，提高了准确性。具体由nameserver完成，具体流程如下：

各NameServer通过抢占特定的临时节点，选出Leader节点；
各NameServer向master节点发送消息，根据发送发送探活消息失败率是否超过阈值判断是否健康，并将状态更新到此brokername下对应的NameServer节点中；
NameServer的master发现自己跟Broker的master链接异常，然后检查其他节点是否也发现master掉线，如果掉线数量超过阈值，启动切换流程；
将broker master切换为slave；
从原有的slave中，选出offset最大的broker，并将其切换为master；

关于DDMQ部署安装，可参照GitHub的说明。

GitHub 仓库地址：https://github.com/didi/DDMQ

作者介绍

臧磊，毕业于北京大学软件工程研究所，滴滴出行自研消息中间件 DDMQ 开源负责人，曾就职于猿题库和今日头条，长期专注于消息队列等基础设施的研发工作。目前在滴滴出行负责 DDMQ 的产品云化和大数据生态建设等工作。

江海挺，毕业于北京大学软件工程研究所，滴滴出行自研消息中间件 DDMQ 的产品负责人，同时对于开源的 Kafka 和 RocketMQ 等消息系统的架构设计、运行维护有着深入的理解和丰富的经验。

创作场景

支持 Kafka 和 RocketMQ 等消息引擎，滴滴开源分布式消息中间件 DDMQ