眾所周知，RocketMQ 作為一款分布式、隊列模型的消息中間件，具有以下特點：

• 嚴(yán)格保證的消息順序

• 豐富的消息拉取模式

• 高效的訂閱者水平擴(kuò)展能力

• 實時的消息訂閱機(jī)制

• 億級消息堆積能力

在復(fù)雜的應(yīng)用場景中，將 RocketMQ 作為技術(shù)解耦的消息中間件，可以簡化服務(wù)部署，以下是 RocketMQ 在聯(lián)想大數(shù)據(jù)的實踐分享。

場景分析

在聯(lián)想大數(shù)據(jù)中，應(yīng)用 RocketMQ 的使用場景中經(jīng)常會出現(xiàn)：異步請求，應(yīng)用解耦和日志處理等場景情況。

• 異步請求的業(yè)務(wù)處理：

經(jīng)常遇到如下兩種情況，一種為串行方式的業(yè)務(wù)流程（如圖1），另一種為并行方式的業(yè)務(wù)流程（如圖2）。

串行方式：在聯(lián)想大數(shù)據(jù)解決方案中，針對順序化、流程化的業(yè)務(wù)場景經(jīng)常使用串行方式，實現(xiàn)RocketMQ 的技術(shù)解耦。如在某卷煙廠的解決方案中，針對制煙流程，將各個車間的處理流程做為獨立的業(yè)務(wù)體創(chuàng)建一個Topic，對業(yè)務(wù)體中的各個處理階段創(chuàng)建對應(yīng)的Tag，并按照制煙流程順序進(jìn)行數(shù)據(jù)推送、清洗、業(yè)務(wù)處理及監(jiān)控等，如下圖1。

圖1

并行方式：因業(yè)務(wù)的獨立性，處理流程可分開進(jìn)行處理，相互之間沒有業(yè)務(wù)交叉。這種情況下，我們可以考慮使用并行方式對業(yè)務(wù)流程進(jìn)行技術(shù)解耦。在聯(lián)想大數(shù)據(jù)的相關(guān)解決方案中，針對某汽車的數(shù)據(jù)監(jiān)控及相關(guān)畫像的流程中，一部分是基礎(chǔ)業(yè)務(wù)處理流程，另一部分是通過Bin Log 數(shù)據(jù)進(jìn)行數(shù)據(jù)監(jiān)控與消息提醒等附加處理業(yè)務(wù)流程。針對這種場景，我們在給客戶進(jìn)行程序部署時，便采用了并行方式，如圖2。

圖2

• 錯峰削谷

雖然聯(lián)想商城的并發(fā)請求數(shù)不像淘寶、天貓、京東商城等互聯(lián)網(wǎng)公司的并發(fā)請求數(shù)高，但在技術(shù)要求上經(jīng)過多年的業(yè)務(wù)總結(jié)和摸索過程中，總結(jié)出適合聯(lián)想的技術(shù)架構(gòu)體系，以解決高并發(fā)數(shù)據(jù)帶來的業(yè)務(wù)處理壓力，并實現(xiàn)技術(shù)架構(gòu)的高可用。

在應(yīng)對高并發(fā)，處理高可用，保證不丟數(shù)據(jù)的前提下，我們使用RocketMQ做為應(yīng)對特殊的業(yè)務(wù)處理流程的技術(shù)手段，需要在數(shù)據(jù)生產(chǎn)端承接瞬時高數(shù)據(jù)流量，在數(shù)據(jù)消費(fèi)端平穩(wěn)地將數(shù)據(jù)推送到下游業(yè)務(wù)線。

基本處理方法采用業(yè)界普遍的“漏斗”模式，如圖3：

圖3

• 應(yīng)用解耦

對于解耦架構(gòu)來說，在聯(lián)想物聯(lián)網(wǎng)（IOT）的應(yīng)用非常普遍。我們結(jié)合 StreamSets 進(jìn)行二次開發(fā)，使用 StreamSets 通過界面上拖拽的方式制定數(shù)據(jù)流程，并在客戶的解決方案中，說明RocketMQ 區(qū)別于其他 MQ 組件的技術(shù)特點，針對客戶的使用場景進(jìn)行優(yōu)化，使用 RocketMQ 進(jìn)行解耦數(shù)據(jù)。

• 日志處理

RocketMQ 的設(shè)計模式借鑒于 Kafka，且后者經(jīng)常用于日志管理系統(tǒng)充當(dāng)數(shù)據(jù)緩沖的角色。但

Kafka 過度依賴ZooKeeper，而 RockerMQ 則可實現(xiàn)無 ZooKeeper 部署，簡化安裝部署工作，所以，在聯(lián)想大數(shù)據(jù)業(yè)務(wù)線和解決方案中，將 RocketMQ 應(yīng)用于日志處理業(yè)務(wù)，逐漸增加RocketMQ的使用率。

應(yīng)用實例

在聯(lián)想大數(shù)據(jù)解決方案中，目前使用 RocketMQ 的實例也有不少，下面就舉個實例說明一下，我們是如何使用的。

目前，在聯(lián)想大數(shù)據(jù)部門，我主要負(fù)責(zé)數(shù)據(jù)流組件研發(fā)，并基于 StreamSets 開源組件進(jìn)行定制化開發(fā)。在給客戶的解決方案或現(xiàn)場實施中，我們可以通過在界面上的操作，設(shè)定好相關(guān)參數(shù)，便可設(shè)計出符合客戶需求的數(shù)據(jù)流。如圖4所示：

在每一個功能模塊上，我們只需要設(shè)置若干必要的參數(shù)配置，也可以通過在文本框中編寫更多的參數(shù)配置，在啟動數(shù)據(jù)流時，即可加載這些配置，并實現(xiàn)數(shù)據(jù)流中各個功能模塊的初始化、啟動等等功能。

在這個實例中，我通過開發(fā)一個RocketMQ的功能模塊，并設(shè)定一些基本參數(shù)，如 NameServers 組、消費(fèi)組名和 Topic，便可從 RocketMQ 服務(wù)端獲取數(shù)據(jù)。

通過使用這個工具進(jìn)行設(shè)計，大大降低了使用人員的學(xué)習(xí)門檻，而且也簡化了開發(fā)流程。在對外的解決方案或項目交付過程中，極大地贏得了產(chǎn)品和交付工程師的認(rèn)可，在各個 POI 項目中也PK 掉不少大廠公司。

優(yōu)勢

在此僅對比 Kafka，在實際應(yīng)用中所具備的優(yōu)勢：

• 架構(gòu)差異，簡化部署

在集群部署上，Kafka 的部署，必須依賴 ZooKeeper，并實現(xiàn)WaterMark的監(jiān)控和Leader 的選舉。而 RocketMQ 可實現(xiàn)不依賴 ZooKeeper的部署，大大降低使用門檻和學(xué)習(xí)成本。

Kafka 架構(gòu)設(shè)計：

RocketMQ 架構(gòu)設(shè)計，參考官網(wǎng)架構(gòu)設(shè)計：

• 性能優(yōu)勢
  

1、RocketMQ 可支持上萬 Topic 的創(chuàng)建和使用，并且不會影響實例的整體性能及處理能力。

反觀 Kafka，我們在使用 6000 左右的 Topic 時，整個集群性能突然下降，并有部分節(jié)點出現(xiàn)卡頓現(xiàn)象。

2、寫入效率雖略低，但磁盤IO 不是瓶頸。

在實際測試過程中，同時寫入Kafka 和RocketMQ 進(jìn)行測試：

Kafka 的吞吐量高達(dá)15~17w/s，體現(xiàn)出較高的吞吐量。這主要取決于它的隊列模式保證了寫磁盤的過程是線性 IO，但此時 broker 磁盤 IO 已達(dá)瓶頸，寫入響應(yīng)已經(jīng)出現(xiàn)略大的延時，有小部分?jǐn)?shù)據(jù)出現(xiàn)重試寫入。

RocketMQ 的吞吐量基本保證在11~12w/s，磁盤 IO 率雖已接近100%，但消息寫入內(nèi)存后即返回ack，由單獨的線程專門做刷盤的操作，所有的消息均是順序?qū)懳募?/span>

在“坑”中摸爬滾打

在近些年的使用中，聯(lián)想大數(shù)據(jù)逐漸在提高 RocketMQ 的使用率，不僅僅因為其具有區(qū)別于其他 MQ 消息中間件的優(yōu)勢，并且學(xué)習(xí)成本略低于 Kafka，更重要的是 RocketMQ 是阿里開源的消息組件，經(jīng)過大量的生產(chǎn)實踐，且在公司內(nèi)部經(jīng)歷多年的版本更新，達(dá)到一個相當(dāng)穩(wěn)定的版本，而且各種學(xué)習(xí)資料也是相當(dāng)豐富。

因此，在聯(lián)想內(nèi)部開始嘗試 RocketMQ 作為各個業(yè)務(wù)線和解決方案中推薦使用的消息中間件。盡管在應(yīng)用一種新的技術(shù)過程中會遇到各種各樣的“坑”，但是在摸爬滾打的過程中我們痛苦并快樂著。

下面總結(jié)一下，我們遇到的一些比較有特點的“坑”及相應(yīng)的解決方法：

坑一：???

因consume offset不能與commitlog同時刷盤，導(dǎo)致offset不能對應(yīng)數(shù)據(jù)。

因為consume offset 最終要索引到commit log，假如commit log 沒有對應(yīng)的數(shù)據(jù)，那么

consume queue 保存的這個offset也沒有意義，所以最終就算有了這個offset，還是要根據(jù)commit log 來修復(fù)一遍，因為他們不是一起刷盤的。

所以，我們對源碼進(jìn)行了一定優(yōu)化，將 consume offset 和commit log 通過一個事務(wù)進(jìn)行刷盤，保證每一個 consume offset 與 commit log 一一對應(yīng)。

坑二：???

RocketMQ 的common包MixAll類中，默認(rèn)指定WS使用8080端口，不能動態(tài)設(shè)置。

因為8080端口一般為Web應(yīng)用使用端口，但當(dāng)啟動 RocketMQ 后，發(fā)現(xiàn)此端口被占用，導(dǎo)致某個Web應(yīng)用程序不能正常啟動。針對這個問題，我們在社區(qū)Jira中看到類似的Issue，并提供了相應(yīng)的Bugfix方法。所以，我們在使用過程中，基于源碼進(jìn)行了二次開發(fā)，并在 RocketMQ 的配置文件中增加了對此端口的動態(tài)配置項。

在使用和學(xué)習(xí)過程中，還有很多的問題，我們?nèi)蕴幱趯W(xué)習(xí)和提高的階段。

總結(jié)

通過對 RocketMQ 的學(xué)習(xí)和使用，聯(lián)想大數(shù)據(jù)在對外項目和解決方案中，不僅僅可以使用 Kafka 作為消息中間件進(jìn)行數(shù)據(jù)解耦，還能夠借助 RocketMQ，進(jìn)一步豐富應(yīng)對不同使用場景的消息解決方案。

對于 RocketMQ，聯(lián)想大數(shù)據(jù)還處于認(rèn)識學(xué)習(xí)的過程中，目前我們更多地是在使用它，并沒有完全研究透徹。希望以后積極參與到社區(qū)的討論和研究中，貢獻(xiàn)自己的一份力量。

本文不涉及公司專利，僅為本人工作之余對 RocketMQ 在業(yè)務(wù)上的技術(shù)梳理和總結(jié)。

 本文作者：

雷明，現(xiàn)就職于聯(lián)想大數(shù)據(jù)團(tuán)隊。