DDMQ 具有如下的優(yōu)秀特性：

• 低延遲高吞吐：毫秒級延遲，單機(jī)百萬條消息吞吐。

• 豐富的消息類型：具備實(shí)時消息、延時消息和分布式事務(wù)消息。

• 海量消息存儲，支持消息回溯消費(fèi)：支持 RocketMQ 和 Kafka 作為實(shí)時消息的存儲引擎，使用 RocksDB 作為延時消息的存儲引擎。

• 秒級延時消息：支持單條消息設(shè)置精確到秒級的延遲時間，提供普通延時消息和循環(huán)延時消息。

• 多語言客戶端，提供了主流開發(fā)語言 SDK，包括 PHP, Java, Go, C/C++, Python，在 API 上保持著最易使用的 High Level 形式。

• 多種消費(fèi)方式：支持通過 Thrift RPC 拉取、HTTP 推送和第三方存儲直寫的方式消費(fèi)消息。

• 支持靈活的消息過濾和轉(zhuǎn)換功能：通過使用 Groovy 腳本在服務(wù)端進(jìn)行消息體的轉(zhuǎn)換和過濾，能做有效減少客戶端和服務(wù)器的數(shù)據(jù)傳輸量，減輕客戶端處理消息的負(fù)載。

• 統(tǒng)一的 Web 控制臺：方便用戶管理 Topic 等資源，通過控制臺可以實(shí)現(xiàn)配置生產(chǎn)和消費(fèi)的限流值、消費(fèi)方式、Groovy 腳本、啟停消費(fèi)、重置消費(fèi)進(jìn)度等功能。

• 完善的監(jiān)控配套：提供模塊的健康檢查和消息堆積告警功能。

消息隊列作為構(gòu)建現(xiàn)代分布式應(yīng)用所必備的基礎(chǔ)設(shè)施，有著廣泛的應(yīng)用場景。

• 削峰填谷

• 在秒殺等場景下會導(dǎo)致短時間流量的暴漲，下游系統(tǒng)會因?yàn)槿鄙俦Ｗo(hù)而過載甚至崩潰。DDMQ 提供的海量堆積能力和消費(fèi)限流能夠確保下游系統(tǒng)的平穩(wěn)運(yùn)行。

• 異步解耦

• 通過上下游系統(tǒng)的松耦合設(shè)計，可以保證上游系統(tǒng)不會因?yàn)橄掠蜗到y(tǒng)的宕機(jī)而不可用。確保主流程的正常穩(wěn)定運(yùn)行。

• 順序消息

• 現(xiàn)實(shí)中需要保證順序的場景很多，比如訂單系統(tǒng)中訂單創(chuàng)建、支付、退款等流程，均需要保證順序。 DDMQ 提供的順序消費(fèi)功能可以保證消息的先進(jìn)先出。

• 事務(wù)消息

• 在微服務(wù)的場景下，通過 DDMQ 的事務(wù)消息能夠達(dá)到分布式事務(wù)的最終一致性。

下面這張圖描述了 DDMQ 的總體架構(gòu)。主要包括 Broker Cluster、Producer Proxy Cluster（以下簡稱 PProxy），Consumer Proxy Cluster（以下簡稱 CProxy），SDK，Console 等模塊。

Broker Cluster 是 DDMQ 的消息存儲層。使用 RocketMQ 作為實(shí)時消息的存儲引擎（同時也支持使用 Kafka），Chronos 則是我們基于 RocksDB 自研的延時消息存儲引擎。

PProxy 是 DDMQ 的生產(chǎn)代理服務(wù), 內(nèi)置 Thrift RPC Server，生產(chǎn) SDK 通過 RPC 調(diào)用將消息發(fā)送給 PProxy，然后再由 PProxy 負(fù)責(zé)將消息生產(chǎn)到具體的 Broker 中去，在 PProxy 中我們實(shí)現(xiàn)了生產(chǎn)限流、重試和消息批量生產(chǎn)等功能。

CProxy 是 DDMQ 的消費(fèi)代理服務(wù)，也內(nèi)置了 Thrift RPC Server，當(dāng)選擇 SDK 消費(fèi)時，消費(fèi)方以 pull 的方式從 CProxy 中拉取消息，由于 CProxy 中的 PullBuffer 提前緩存了一定數(shù)量的待消費(fèi)消息，因此消費(fèi)的延遲很低。如果選擇 HTTP 方式消費(fèi)，則直接由 CProxy 將消息推送到業(yè)務(wù)指定的回調(diào) URL 地址。在 CProxy 中，我們實(shí)現(xiàn)了消息過濾（通過編寫 Groovy 腳本）、消息體轉(zhuǎn)換（Transit）、重試、消費(fèi)限流、順序消費(fèi)內(nèi)部排序等功能。

Console 是 DDMQ 的控制臺，用戶通過控制臺申請 Topic、Group 等資源。Topic 等數(shù)據(jù)會持久化到 MySQL 并推送到 Zookeeper；PProxy 和 CProxy 通過讀取、監(jiān)聽 Zookeeper 上的 Topic 和 Group 數(shù)據(jù)來實(shí)時控制消息的生產(chǎn)和消費(fèi)邏輯。

DDMQ 選擇 Proxy+SDK 的架構(gòu)，主要有這幾個好處：

• 方便多語言 SDK 的實(shí)現(xiàn)，由于滴滴內(nèi)部使用的技術(shù)棧比較多，將主要邏輯放在 Proxy 上有利于降低 SDK 的復(fù)雜度，讓 SDK 的開發(fā)速度大大加快。目前在滴滴內(nèi)部支持 PHP, Go , C/C++, Java, Python, Node.js 等語言的 SDK 實(shí)現(xiàn)。

• 存儲層業(yè)務(wù)無感知，由于 Proxy 層屏蔽了后面的 RocketMQ 或 Kafka，使得存儲層的切換可以做到業(yè)務(wù)無感知。

• 加快新功能迭代速度，新功能的開發(fā)都在 Proxy 層實(shí)現(xiàn)，降低了 SDK 的升級頻率。

在開源版本的 RocketMQ 里提供了多種固定延遲 level 的延時消息支持，可以發(fā)送幾個固定的延時時間的延時消息，比如延時 10s, 30s…，但是這種不同延時 level 的延時消息并不能滿足滴滴內(nèi)部眾多業(yè)務(wù)方的需求，我們需要的是任意時間精度的延時。因次我們基于 RocksDB 自研了延時消息隊列 Chronos，以 DDMQ 子模塊的形式對外提供服務(wù)。

上面這張圖描述了 Chronos 的總體結(jié)構(gòu)；簡單來說，生產(chǎn) SDK 通過 PProxy 提供的 sendDelay RPC 將延時消息發(fā)送到 PProxy， 然后由 PProxy 將消息生產(chǎn)到 Chronos 固定的內(nèi)部 topic 上（chronos_inner_xxx）。Chronos 模塊再去消費(fèi) inner topic 的消息并將消息存儲到本地的 RocksDB 里去?；诒镜貎?nèi)置的 RocksDB 存儲引擎構(gòu)造一個時間輪服務(wù)，會將到期的消息再發(fā)送給 PProxy，以供業(yè)務(wù)方消費(fèi)或 HTTP 推送給業(yè)務(wù)方。

熟悉 RocketMQ 的同學(xué)應(yīng)該知道，目前開源版本的 RocketMQ broker 是沒有主從自動切換的。如果 Master 掛了，那就寫不進(jìn)去了。然后 Slave 只能提供只讀的功能。當(dāng)然如果你的 topic 在多個主節(jié)點(diǎn)上都創(chuàng)建了，雖然不會完全寫不進(jìn)去，但是對單分片順序消費(fèi)的場景，還是會產(chǎn)生影響。所以我們就自己加了一套主從自動切換的功能。

結(jié)合 RocketMQ 現(xiàn)有的結(jié)構(gòu)，可以采用如上結(jié)構(gòu)，探活采用多個節(jié)點(diǎn)同時向 master 發(fā)送探測消息的方式，相對心跳方式，提高了準(zhǔn)確性。具體由 nameserver 完成，具體流程如下：

1. 各 NameServer 通過搶占特定的臨時節(jié)點(diǎn)，選出 Leader 節(jié)點(diǎn)；

2. 各 NameServer 向 master 節(jié)點(diǎn)發(fā)送消息，根據(jù)發(fā)送發(fā)送探活消息失敗率是否超過閾值判斷是否健康，并將狀態(tài)更新到此 brokername 下對應(yīng)的 NameServer 節(jié)點(diǎn)中；

3. NameServer 的 master 發(fā)現(xiàn)自己跟 Broker 的 master 鏈接異常，然后檢查其他節(jié)點(diǎn)是否也發(fā)現(xiàn) master 掉線，如果掉線數(shù)量超過閾值，啟動切換流程；

4. 將 broker master 切換為 slave；

5. 從原有的 slave 中，選出 offset 最大的 broker，并將其切換為 master；

關(guān)于 DDMQ 部署安裝，可參照 GitHub 的說明。

GitHub 倉庫地址：https://github.com/didi/DDMQ