*作者：* *艾陽坤*

RocketMQ 5.0 SDK 採用了全新的 API，使用 gRPC 作為通訊層的實現，並在可觀測性上做了很大幅度的提升。

## 全新統一的 API

此處的 API 並不單單只是介面上的定義，同時也規定了各個介面不同的方法和行為，明確了整個訊息模型。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/834abacf75c944e6b87a3f08449360bf~tplv-k3u1fbpfcp-zoom-1.image "1.png")

RocketMQ 過去的 API 從第一版開始，至今已經過了很長時間，長期依賴是一個缺乏變革的狀態，對於一些中途打算廢棄或者變更的 API 也沒有進行後續的迭代。此外，介面的定義也不夠清晰。因此，RocketMQ 希望在 5.0 中能夠建立一個統一的規範，精簡整個 API，透過引入 builder 模式來引入更多的不變性，同時做好異常管理，給開發者和使用者一個更加清爽的面貌。

目前 C++ 和 Java 已經進行了 5.0 API 的定義與實現，更多語言的支援也陸續在路上了。我們也歡迎更多的開發者可以參與到社群的工作中來。這裡給出 5.0 客戶端的倉庫連結：

> <https:>

除了在上述介面上做的一些修改之外， RocketMQ 5.0 還規定了四種新的不同的客戶端型別，即 Producer/Push Consumer/Simple Consumer/Pull Consumer。

其中 Pull Consumer 還在開發中；Producer 主要還是做了介面裁剪，規範了異常管理。在功能上其實並沒有做一些顛覆性的改變。Push Consumer 也是比較類似的；Simple consumer 將更多的權利將下發給使用者，是一種使用者可以主動控制訊息接收與處理過程的消費者，特別的，5.0 的 SDK 中，Push Consumer 和 Simple Consumer 都採用 RocketMQ 的 pop 機制進行實現，一些社群的同學可能已經熟悉了。

如果使用者並不一定想控制或者關心整個訊息的接收過程，只在乎訊息的消費過程的話，這個時候 Push Consumer 可能是一個更好的選擇。

RocketMQ 5.0 定義了四種不同的訊息型別。過去的開源版本中其實我們並沒有去突出訊息型別這樣一個概念，後續出於維護及運維方面的需要以及模型定義的完備，才讓今天的 5.0 有了訊息型別的這樣一個概念。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3ef9c7e0d6c44482aea3ef69f7beecf7~tplv-k3u1fbpfcp-zoom-1.image "2.png")

1、**NORMAL**：普通訊息。

2、**FIFO**：滿足先入先出的語義。使用者可以透過定義 message group 來控制訊息間的消費順序。例如圖中的 fruit 這個 topic 下，可以定義不同的 message group，在 apple 這個 message group 下，會按照傳送順序決定訊息被消費的順序，並且不同的 message group 之間不會互相干擾。

3、**TRANSACTIONAL**：可以將一條或多條訊息包成一個事務，終端使用者可以根據自己的業務結果選擇提交或者回滾。

4、**DELAY**：使用者可以自主地設定訊息的定時時間，相比之前開源版本僅允許使用者設定定時/延遲級別，5.0 的實現中還講允許使用者設定更精確的時間戳。

以上四種訊息是互斥的，我們會在 topic 的後設資料去標識它的型別。實際在訊息傳送的時候如果如果出現了嘗試傳送的訊息型別與 topic 型別不匹配的情況，也會做一些限制。

## 實現

RocketMQ 5.0 在客戶端的啟動過程中提前進行了更多的準備工作。比如使用者提前設定要傳送訊息的 topic 時，Producer 會在啟動過程中嘗試獲取對應 topic 的路由。在過去的客戶端實現中，在針對於某個 topic 第一次傳送訊息時，需要先獲取路由，這裡就會有一個類似冷啟動的過程。

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/888951220de0476b9a2dac1e46b8b9e7~tplv-k3u1fbpfcp-zoom-1.image "3.png")

提前獲取 Topic 的路由資訊有兩點好處：

1. 不阻塞後面的傳送，讓訊息的傳送僅僅觸發傳送這一個動作。

2. 錯誤前置，比如使用者要往一個不存在 Topic 傳送訊息時，因為路由的獲取參與到整個客戶端的啟動過程，獲取路由不成功，那整個客戶端啟動可能就會失敗，使用者也是拿不到對應的 Producer 物件的。

類似的，Consumer 的啟動也會有這樣的一個過程。

除此之外，我們在客戶端和服務端之間增加了一個 Telemetry 的部分，它會在客戶端和服務端之間建立起了一個進行雙向資料通訊的通道，客戶端和服務端會在這個過程中溝通配置，比如服務端可以實現對客戶端配置的下發，更好地管理客戶端。此外，Telemetry 也可以將本地配置主動上報給服務端，讓服務端也可以對客戶端的設定有更好的瞭解。Telemetry 通道也會在客戶端啟動時嘗試建立，如果這個通道沒有建立成功，也會影響客戶端的啟動。

總的來說，客戶端的啟動過程會盡可能將所有準備工作做好。同時在客戶端和服務端之間建立 Telemetry 這樣一個通訊通道。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/613095ad36534376b5ce9a7aeb5595c6~tplv-k3u1fbpfcp-zoom-1.image "4.png")

客戶端內部存在一些週期性的任務，比如路由的定時更新以及客戶端往服務端傳送心跳等。對於上文中提到的 Telemetry 過程中，客戶端的配置上報也是週期性的。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c52967ad1eb0453583b1211f6a706292~tplv-k3u1fbpfcp-zoom-1.image "5.png")

Producer 在 RocketMQ 5.0 中的具體工作流程

訊息在傳送時，會檢查是否已經獲取對應 topic 的路由資訊。如果已經獲取，則嘗試在路由中選取佇列，隨即檢視要傳送的訊息的型別是否與 topic 型別匹配，如果匹配，則進行訊息傳送。如果傳送成功，則返回；否則，判斷當前重試次數是否超出使用者設定的上限，如果超出，則返回失敗；否則輪轉到下一個佇列，然後對新的佇列進行重試直到消費次數超出上線。而如果啟動過程中沒有提前獲取路由，那麼訊息傳送時依然會先嚐試獲取路由，然後再進行下一步操作。

另外一點相對於老客戶端較大的改變在於，客戶端從底層 RPC 互動到上層的業務邏輯全部採用非同步實現。Producer 依然會提供一個同步傳送介面和非同步傳送介面，但同步的方法也是使用非同步來實現，整個邏輯非常統一和清爽。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aba0fbd9437049dcb2b4e1e1e16ccaa1~tplv-k3u1fbpfcp-zoom-1.image "6.png")

Push Consumer 分為兩部分，訊息的接收和消費。

訊息接收流程為：客戶端需要不斷地從服務端拉取訊息，並將訊息快取。Push Consumer 會將訊息先快取到客戶端的本地，再進行消費，因此它會判斷客戶端本地的 Cache 是否已滿，如果已滿，則隔一段時間再判斷，直到訊息被客戶端消費，Cache 尚有餘量時再進行訊息拉取。為了避免出現一些記憶體問題，Cache 的大小也是被嚴格限制的。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/59efcecbceb4463ca48055e7b56b91d9~tplv-k3u1fbpfcp-zoom-1.image "7.png")

訊息消費過程分為兩個型別，順序型別和非順序型別。

其中非順序型別即併發消費。消費者會先從 Cache 中獲取訊息，然後嘗試消費訊息，消費後再將訊息從 Cache 中移除。訊息消費成功時，會嘗試將訊息 ACK ，消費流程結束；如果消費失敗，則嘗試修改訊息的可見時間，即決定下一次什麼時候可見。

順序消費指對於同一個 Group 的訊息，最終消費時一定是前一條訊息被消費過並且得到確認後，後面的訊息才能夠繼續消費。而消費過程與非順序消費類似，首先嚐試從 Cache 中拉取訊息，如果消費成功，則將訊息 ACK。ACK 成功後，將其從 Cache 中移除。特別地，如果消費失敗，會 suspend 一段時間，然後繼續嘗試對訊息進行消費。此時會判斷消費次數是否超限，如果超限，則會嘗試將訊息放入死信佇列中。

相對於非順序消費，順序消費更復雜，因為其需要保證前一個訊息消費成功後才能對後面的訊息進行消費。順序消費的消費邏輯是基於 message group 隔離的。message group 會在傳送時做雜湊，從而保證 message group 的訊息最終會落在一個佇列上，順序消費模式本質上保證佇列內部消費的順序。

此外，因為不同 message group 的順序訊息最終可能會對映到同一個佇列上，這可能會導致不同的 message group 之間的消費形成阻塞，因此服務端未來會實現一個虛擬佇列，讓不同的 message group 對映到客戶端的虛擬佇列，保證他們之間沒有任何阻塞，從而加速資料訊息的消費過程。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c5aaf1bfac0b434eaef36d158f6936ce~tplv-k3u1fbpfcp-zoom-1.image "8.png")

對於 Simple Consumer，使用者可以主動控制訊息接收和確認的流程。比如使用者收到訊息後，可以根據業務決定是否過一段時間再消費該訊息，或者不需要再收到該訊息。消費成功後將訊息 ACK 掉，如果失敗則主動修改可見時間，選擇該訊息下一次什麼時候可見，即由使用者自發地控制整個過程。

## 可觀測性

### Shaded Logback

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/032d97361fe842c691c3fb03621e01bc~tplv-k3u1fbpfcp-zoom-1.image "9.png")

因為歷史原因，RocketMQ 的老客戶端並不是面向 SLF4J 進行程式設計的，而是面向 logback 的。這麼做的目的其實是為了方便快捷地獲取日誌，不需要讓使用者自己去手動配置。

RocketMQ 中專門有一個 logging 模組是負責日誌部分的，像使用者自己使用了 logback ，RocketMQ SDK 如果也直接去使用 logback，兩者就會產生各種各樣的衝突，這個 logging 模組就是用來保證這一層隔離性的。

但是 logging 模組本身的實現並不是很優雅，也帶來了一定的維護成本。因此我們採用了 shade logback 的方式來達到上文提到的隔離性。shaded logback 不僅能夠避免使用者的 logback 與 RocketMQ 自己的 logback 衝突，還能保持較好的可維護性，將來要想在日誌上去做一些修改，也來得容易的多。

具體來說，使用者的 logback 會採用 logback.xml 的配置檔案，透過 shade logback， RocketMQ 5.0 的客戶端會使用 rocketmq.logback.xml 的配置檔案，因此在配置部分就已經完全隔離了，同時在 shade 的過程中，還對原生 logback 中使用到的一些環境變數和系統變數也進行了修改，這樣就保證了兩者的徹底隔離。

另外，使用 shadeed logback 之後，RocketMQ 5.0 客戶端中的日誌部分就全都是面向 SLF4J 來進行程式設計的了，這樣一來，如果我們未來想讓使用者自己去完全控制日誌的話，提供一個去除 logback 的 SDK 就可以了，非常方便。

### Trace

5.0 的訊息軌跡基於 OpenTelemetry 模型進行定義與實現，訊息傳送或接收訊息的流程被定義為一個個獨立的 span ，這一套 span 規範參照了 OpenTelemetry 關於 Messaging 的定義。圖中這裡 Process P 表示 Producer ，Process C 表示 Consumer。訊息的全生命週期，從傳送到接收到消費，就可以具象化為這樣一個個的 span。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8a248fdbe95a4a8bbaa8b1100caa2bd1~tplv-k3u1fbpfcp-zoom-1.image "10.png")

比如，針對 Push Consumer 而言，先會有一個 receive 的 span 來表示從服務端獲取訊息的過程，收到訊息後到會先等待訊息被處理，這個也就是 await span 表示的過程，訊息被處理則對應圖中的 process span，訊息消費結束之後，向服務端反饋訊息處理結果也會有專門的 span 進行描述。

我們透過 parent 和 link 來講所有的這些 span 關聯起來，這樣透過一條訊息的任意一個 span，就可以獲得這條訊息全生命週期的所有 span。

不僅如此，使用者還將允許可以設定一個 span context 與自己的業務鏈路進行關聯，將 RocketMQ 5.0 的訊息軌跡本身嵌入進自己的全鏈路可觀測系統中去。

### Metrics

Tracing 相對來說成本是比較高的，因為一條訊息從傳送到接收，可能會有很多流程，這就伴隨著很多的 span，這就導致相對來說，tracing 資料的儲存查詢成本相對來說比較高。我們希望診斷整個 SDK 的健康狀況，同時又不希望收集太多的 tracing 資訊提高成本，此時提供一份 metrics 資料就能比較好地滿足我們的需求。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0697b216222244dbb6b7816578b842a1~tplv-k3u1fbpfcp-zoom-1.image "11.png")

在 SDK 的 metrics 中我們新增了諸多指標，包括不限於 Producer 中訊息傳送延時，Push Consumer 中訊息的消費耗時和訊息快取量，可以幫助使用者和運維者更快更好地發現異常。

5.0 中 SDK 的 metrics 也是基於 OpenTelemetry 進行實現的。以 Java程式為例，OpenTelemetry 對於 Java 的實現本身提供了一個 agent，agent 在執行時會打點採集 SDK 的一些 tracing/metrics 資訊，並將它上報到對應的 metric collector 中，這種透過 agent 來降低無侵入式資料採集的方式被稱之為 automatic instrumentation，而手動在程式碼中實現打點採集的方式則被稱之 manual instrumentation。對於 metrics 我們目前還是採用 manual instrumentation 的方式來進行資料的採集和上報的。服務端會告知客戶端對應的 collector 的地址，然後客戶端將 Metrics 資料上傳到對應的 collector 當中去。

*作者介紹：*

*艾陽坤，Apache RocketMQ 5.0 Java SDK 作者，CNCF Envoy Contributor，CNCF OpenTelemetry Contributor，阿里雲智慧高階開發工程師。*

## 加入 Apache RocketMQ 社群

十年鑄劍，Apache RocketMQ 的成長離不開全球接近 500 位開發者的積極參與貢獻，相信在下個版本你就是 Apache RocketMQ 的貢獻者，在社群不僅可以結識社群大牛，提升技術水平，也可以提升個人影響力，促進自身成長。  
  
社群 5.0 版本正在進行著如火如荼的開發，另外還有接近 30 個 SIG（興趣小組）等你加入，歡迎立志打造世界級分散式系統的同學加入社群，新增社群開發者微信：rocketmq666 即可進群，參與貢獻，打造下一代訊息、事件、流融合處理平臺。  
歡迎您掃描下方二維碼加入釘釘群一起溝通交流～

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c8790e5d6c6f4a7f95ed1624bf776554~tplv-k3u1fbpfcp-zoom-1.image "12.png")

點選[此處](https://www.aliyun.com/product/rocketmq)，進入官網瞭解更多詳情～</https:>

RocketMQ 5.0 API 與 SDK 的演進

相關文章