更多干货内容请关注微信公众号“AI 前线”(ID:ai-front) 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 的架构,主要有这几个好处:
在开源版本的 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 的同学应该知道,目前开源版本的 RocketMQ broker 是没有主从自动切换的。如果 Master 挂了,那就写不进去了。然后 Slave 只能提供只读的功能。当然如果你的 topic 在多个主节点上都创建了,虽然不会完全写不进去,但是对单分片顺序消费的场景,还是会产生影响。所以我们就自己加了一套主从自动切换的功能。 结合 RocketMQ 现有的结构,可以采用如上结构,探活采用多个节点同时向 master 发送探测消息的方式,相对心跳方式,提高了准确性。具体由 nameserver 完成,具体流程如下:
关于 DDMQ 部署安装,可参照 GitHub 的说明。 GitHub 仓库地址:https://github.com/didi/DDMQ 臧磊,毕业于北京大学软件工程研究所,滴滴出行自研消息中间件 DDMQ 开源负责人,曾就职于猿题库和今日头条,长期专注于消息队列等基础设施的研发工作。目前在滴滴出行负责 DDMQ 的产品云化和大数据生态建设等工作。 江海挺,毕业于北京大学软件工程研究所,滴滴出行自研消息中间件 DDMQ 的产品负责人,同时对于开源的 Kafka 和 RocketMQ 等消息系统的架构设计、运行维护有着深入的理解和丰富的经验。 |
|