<本文已參與 RocketMQ Summit 優秀案例征文活動，點此了解詳情>

緣起

對于Apache RocketMQ的了解，追溯起來，可以說是從開源初始，就認識到了它。那時候的它，還是個幼年，沒有成熟的社區，也沒有好的機制去運作。本身，也不算是成熟的產品。

但是，在阿里強大的技術背景驅動下，隨著業務的支撐，它慢慢得到了長遠的發展，更多的走向了大眾的視野，也慢慢成為了一款優秀的消息隊列中間件。

在技術選型中，可以作為一名佼佼者，為各個技術負責人提供技術支持。

緣與業務

對于我司傳統的業務場景以及相關產品中，一般不會涉及到消息中間件的涉及。很有幸，公司的發展以及壯大，新的產品、新的業務場景進行了拓展。我司，也參與了智慧城市的相關業務場景建設。

很多的產品，屬于互聯網平臺，因此，對于消息隊列中間件的需求，就隨之誕生，也就比較迫切。借助消息隊列其減少相應所需的時間和削峰，降低系統耦合性的相關特性，構建更加健壯的平臺產品。

實踐從業務中來，到業務中去。本次分享便從一個企業服務平臺的建設才講述。

業務場景如下所示：

我司與政府大數據局，參與共建一個企業與企業、企業與政府之間互聯互通的、信息交互的一個新型互聯網平臺。平臺中，為企業提供了最便捷的溝通入口。

根據政府的需求，企業可以在線，實現政策申報、政策享受等一系列先進的、優秀的、便捷、快速的政府服務。同時，企業在平臺中，跟其他企業可以實現在線服務申請、在線溝通。其中，平臺上企業個人中心中會有個模塊會消息中心。展示了，企業收到的來自各個方面的消息通知。

場景如下圖所示：

緣與技術

本身作為分布式消息業務需要，同時為了降低系統耦合性，選擇消息隊列中間件，來完成消息中心的建設。

技術選型

四種常用的分布式消息隊列開源軟件：Kafka、ActiveMQ、RabbitMQ?及?RocketMQ。

在分布式消息隊列的江湖里，Kafka 憑借其優秀的性能占據重要一席。

Kafka 作為流平臺具有以下三種能力：

發布和訂閱記錄流，類似于消息隊列或企業消息系統；

具有容錯能力，且可以持久化的方式存儲記錄流；

當記錄流產生時（發生時），可及時對其進行處理。

Kafka 適用于兩類應用：

建立實時流數據管道，在系統或應用之間可靠地獲取數據；

建立對數據流進行轉換或反應的實時流應用程序。

目前，Kafka更多的用于數據量大的大數據平臺項目。

ActiveMQ 由 Apache 出品，據官網介紹，它是最流行和最強大的開源消息總線。ActiveMQ 非常快速，支持多種語言的客戶端和協議，而且可以非常容易地嵌入到企業的應用環境中，并有許多高級功能。

ActiveMQ 基于 Java 語言開發，從使用的便捷性與開源程度，是可以承擔起更多的職責。但是，目前由于

社區活躍度較低，更新慢，增加維護成本；

網絡資料顯示，ActiveMQ 存在一些莫名其妙的問題，會丟失消息；

目前，官方將重心放到 ActiveMQ 6.0 下一代產品 Apollo 上，對 5.x 的維護較少；

不適合用于上千個隊列的應用場景。

因此，不適合更新迭代速度的互聯網平臺。

RabbitMQ 是流行的開源消息隊列系統，支持多種客戶端，如 Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX、持久化。用于在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。但是，目前由于

盡管結合 Erlang 語言本身的并發優勢，性能較好，但是不利于做二次開發和維護；

實現了代理架構，意味著消息在發送到客戶端之前可以在中央節點上排隊。此特性使得 RabbitMQ 易于使用和部署，但使得其運行速度較慢，因為中央節點增加了延遲，消息封裝后也比較大；

需要學習比較復雜的接口和協議，學習和維護成本較高。

因此，綜合考慮沒有選擇。

RocketMQ 由阿里研發團隊開發的分布式隊列，側重于消息的順序投遞，具有高吞吐量、可靠性等特征。RocketMQ 與ActiveMQ一樣，用 Java 語言實現，在設計時參考了 Kafka，并做出了自己的改進，在消息可靠性上比 Kafka 更好，RocketMQ 已經被業界多個大型互聯網公司采用。

所謂實踐是檢驗真理的唯一標準，實際應用中的表現比文字更具說服力。在阿里內部，RocketMQ 很好地服務了集團大大小小上千個應用，在每年的雙十一當天，更有不可思議的萬億級消息通過 RocketMQ 流轉（在 2017 年的雙 11 當天，整個阿里巴巴集團通過 RocketMQ 流轉的線上消息達到了萬億級，峰值 TPS 達到 5600 萬），在阿里大中臺策略上發揮著舉足輕重的作用。

目前，社區活躍，開源程度高，本身經得起業務場景的考驗，因此最終選型為RocketMQ。

部署架構

RocketMQ支持部署場景的自定義，同時支持高可用的部署方案。

對于當前平臺的建設，存在DMZ區、金宏網區網絡隔離環境。對于平臺的中間件部署存在一些復雜的網絡要求。

借用官網對于部署架構的圖示：

對于我們在實踐中的部署，同樣采用了官方的部署實踐。采用了多Master、多Slave異步復制的方式，即使磁盤損壞，消息丟失得非常少，消息實時性不會受影響，因為 Master 宕機后，消費者仍然可以從 Slave 消費，此過程對應用透明，不需要人工干預，性能同多 Master 模式幾乎一樣。

技術實現

對于RocketMQ的客戶端消費者、服務端生產者來講，采用Springboot作為技術開發框架，實現起來非常簡單。

引入對應的POM依賴

<dependency><groupId>org.apache.rocketmq</groupId><artifactId>rocketmq-spring-boot-starter</artifactId><version>2.0.3</version> </dependency>

應用配置文件修改

rocketmq:name-server: xxxx:9876producer:group: base_group_syncMsgsend-message-timeout: 5000retry-times-when-send-failed: 2max-message-size: 4194304

對應的添加相關注解、實現業務代碼即可。

使用方便，功能強大，對于開發者來說非常友好，是一個很好的選擇。

緣與分布式事務

寫到這里，同時也描述下，采用了微服務技術解決方案后，在很多場景下，會產生分布式事務。那么，除了自實現，分布式事務框架，同時，我們可以采用消息隊列來實現。

在本次實踐中，我們有過進一步的實踐。在此，就不多說。

緣與未來

實踐看來，對于RocketMQ的落地過程中，雖有坎坷，但是達到了預想的效果。社區的文檔也是比較滿足實際落地需要，總體來說，是不錯的。

在此，也希望社區越做越好吧，未來可期。

總結

以上是生活随笔為你收集整理的Apache RocketMQ在我司的最佳实践--智慧政务场景下的分布式消息与分布式事务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。