DDMQ: Didi's Open‑Source Distributed Message Queue

Didi Mobility's messaging service team recently open‑sourced its internally widely used distributed messaging middleware product DDMQ, an enterprise‑grade message queue designed to provide low latency, high concurrency, high availability, and high reliability.

Product Features

Low latency and high throughput: millisecond‑level latency, millions of messages per second on a single node.

Rich message types: real‑time, delayed, and distributed transactional messages.

Massive message storage with back‑track consumption: supports RocketMQ and Kafka as real‑time storage engines, and RocksDB for delayed messages.

Second‑level delayed messages: precise per‑second delay, offering both ordinary and cyclic delayed messages.

Multi‑language SDKs: PHP, Java, Go, C/C++, Python, providing a high‑level, easy‑to‑use API.

Multiple consumption methods: Thrift RPC pull, HTTP push, and direct write to third‑party storage.

Flexible message filtering and transformation: Groovy scripts enable server‑side filtering and transformation, reducing data transfer and client load.

Unified web console: manage topics, groups, rate limits, consumption modes, Groovy scripts, start/stop consumption, reset offsets, etc.

Comprehensive monitoring: health checks and message backlog alerts.

Applicable Scenarios

Peak‑shaving : In flash‑sale or similar spikes, DDMQ’s massive buffering and rate‑limiting keep downstream services stable.

Asynchronous decoupling : Loose coupling ensures upstream services remain available even if downstream services fail.

Ordered messages : Guarantees FIFO order for use‑cases such as order creation, payment, and refund workflows.

Transactional messages : Enables eventual consistency for distributed transactions in micro‑service architectures.

Architecture Design

The overall architecture consists of a Broker Cluster, Producer Proxy Cluster (PProxy), Consumer Proxy Cluster (CProxy), SDKs, and a Web Console.

Broker Cluster is the storage layer, using RocketMQ (or Kafka) for real‑time messages and a RocksDB‑based engine (Chronos) for delayed messages.

PProxy acts as the production proxy service, exposing a Thrift RPC server. SDKs send messages to PProxy, which handles rate‑limiting, retries, and batch production before forwarding to the appropriate broker.

CProxy is the consumption proxy service, also with a Thrift RPC server. Consumers can pull messages via RPC (low latency thanks to a pre‑filled PullBuffer) or receive HTTP pushes. CProxy provides server‑side Groovy‑based filtering, body transformation (Transit), retries, rate‑limiting, and ordered consumption.

The Console allows users to create topics, groups, and other resources. Metadata is persisted in MySQL and synchronized to Zookeeper; PProxy and CProxy watch Zookeeper to dynamically adjust production and consumption behavior.

Using a Proxy + SDK architecture brings several benefits: easy multi‑language SDK implementation, storage‑layer transparency, and faster feature iteration without requiring SDK upgrades.

Summary

DDMQ has been running stably within Didi for more than two years, supporting ride‑hailing, car‑service, map, finance, autonomous driving, smart traffic, and food‑delivery businesses. It processes message volumes at the hundred‑billion level with overall availability exceeding five nines (99.999%).

GitHub repository: https://github.com/didi/DDMQ