滴滴开源分布式消息中间件产品DDMQ
滴滴出行消息服务团队近日开源了其内部广泛使用的分布式消息中间件产品 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的升级频率。
总结
DDMQ 已经在滴滴内部稳定运行了两年多时间，支撑了网约车、小桔车服、地图、金融、智能驾驶、智慧交通、外卖等业务的稳定运行。日消息流水达到千亿级别，整体服务可用性超过5个9。
GitHub 仓库地址：
欢迎大家多提issue
-END-
长按二维码
关注
滴滴技术