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

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

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

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

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

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

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

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

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

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

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

• 削峰填谷

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

• 異步解耦

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

• 順序消息

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

• 事務(wù)消息

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 將 broker master 切換為 slave；

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

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

GitHub 倉(cāng)庫(kù)地址：https://github.com/didi/DDMQ