出品 | 滴滴技术git
做者 | 消息服务团队github
滴滴出行消息服务团队近日开源了其内部普遍使用的分布式消息中间件产品 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