滴滴開源分佈式消息中間件產品DDMQ

時間 2019-11-05

標籤滴滴開源分佈式消息中間件產品 ddmq 欄目系統架構简体版

原文原文鏈接

出品 | 滴滴技術git

做者 | 消息服務團隊github

滴滴出行消息服務團隊近日開源了其內部普遍使用的分佈式消息中間件產品 DDMQ，這是一款致力於提供低延遲、高併發、高可用、高可靠消息服務的企業級消息隊列產品。
緩存

1.產品特性

DDMQ 具備以下的優秀特性：服務器

低延遲高吞吐：毫秒級延遲，單機百萬條消息吞吐。架構
豐富的消息類型：具有實時消息、延時消息和分佈式事務消息。併發
海量消息存儲，支持消息回溯消費：支持 RocketMQ 和 Kafka 做爲實時消息的存儲引擎，使用RocksDB 做爲延時消息的存儲引擎。異步
秒級延時消息：支持單條消息設置精確到秒級的延遲時間，提供普通延時消息和循環延時消息。分佈式
多語言客戶端，提供了主流開發語言SDK，包括PHP, Java, Go, C/C++, Python，在API 上保持着最易使用的 High Level 形式。微服務
多種消費方式：支持經過 Thrift RPC拉取、HTTP 推送和第三方存儲直寫的方式消費消息。高併發
支持靈活的消息過濾和轉換功能：經過使用 Groovy 腳本在服務端進行消息體的轉換和過濾，能作有效減小客戶端和服務器的數據傳輸量，減輕客戶端處理消息的負載。
統一的Web控制檯：方便用戶管理Topic等資源，經過控制檯能夠實現配置生產和消費的限流值、消費方式、Groovy腳本、啓停消費、重置消費進度等功能。
完善的監控配套：提供模塊的健康檢查和消息堆積告警功能。

2.適用場景

消息隊列做爲構建現代分佈式應用所必備的基礎設施，有着普遍的應用場景。

削峯填谷
在秒殺等場景下會致使短期流量的暴漲，下游系統會由於缺乏保護而過載甚至崩潰。DDMQ提供的海量堆積能力和消費限流可以確保下游系統的平穩運行。
異步解耦
經過上下游系統的鬆耦合設計，能夠保證上游系統不會由於下游系統的宕機而不可用。確保主流程的正常穩定運行。
順序消息
現實中須要保證順序的場景不少，好比訂單系統中訂單建立、支付、退款等流程，均須要保證順序。 DDMQ提供的順序消費功能能夠保證消息的先進先出。
事務消息
在微服務的場景下，經過DDMQ的事務消息可以達到分佈式事務的最終一致性。

3.架構設計

下面這張圖描述了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的升級頻率。