簡(jiǎn)介
近年來(lái)，淘寶天貓“雙十一”活動(dòng)影響了整個(gè)中國(guó)互聯(lián)網(wǎng)電商的發(fā)展，在“雙十一”的背后，有一系列開放平臺(tái)技術(shù)的使用來(lái)保障電商平臺(tái)的在高峰流量下正常運(yùn)行。而消息中間件RocketMQ就是其中一個(gè)重要的技術(shù)。RocketMQ是阿里推出的一款開源的消息中間件。其前身是MetaQ （Metamorphosis），它并不遵循任何規(guī)范（如JMS,AMQP等），但是參考了各種規(guī)范與同類產(chǎn)品的設(shè)計(jì)思想，但其主要借鑒的產(chǎn)品是Apache Kafka。
就特性來(lái)說(shuō)，RocketMQ主要具有以下幾個(gè)特點(diǎn)：
l 能夠保證嚴(yán)格的消息順序
l 提供推/拉兩種消息模式
l 高效的訂閱者水平擴(kuò)展能力
l 實(shí)時(shí)的消息訂閱機(jī)制
l 億級(jí)消息堆積能力
RocketMQ經(jīng)歷了三個(gè)主要版本迭代
- Metaq（Metamorphosis） 1.x
由開源社區(qū)killme2008（莊曉丹）維護(hù)，最后一次MetaQ的更新時(shí)間為2013年。 - Metaq 2.x
于2012 年10 月份上線，在淘寶內(nèi)部被廣泛使用。 - RocketMQ 3.x
基于阿里巴巴公司內(nèi)部開源共建原則，RocketMQ項(xiàng)目只維護(hù)核心功能，且去除了所有其他運(yùn)行時(shí)依賴，核心功能最簡(jiǎn)化。每個(gè)產(chǎn)品的個(gè)性化需求都在RocketMQ項(xiàng)目之上進(jìn)行深度定制。
RocketMQ目前在GitHub上的版本更新較慢，但是阿里對(duì)外提供了消息中間件的云服務(wù)，并已正式商業(yè)運(yùn)行。目前來(lái)說(shuō)，GitHub上的RocketMQ并沒(méi)有主備自動(dòng)切換，事務(wù)等方面的功能。
一、RocketMQ部署架構(gòu)介紹
RocketMQ使用Name Server集群加Broker集群的方式來(lái)搭建。
RocketMQ需要部署Name Server（名稱服務(wù)器），Name Server是一個(gè)幾乎無(wú)狀態(tài)節(jié)點(diǎn)，可集群部署，節(jié)點(diǎn)之間無(wú)任何信息同步。
Broker（消息服務(wù)器）部署相對(duì)復(fù)雜，Broker分為Master與Slave，一個(gè)Master可以對(duì)應(yīng)多個(gè)Slave，但是一個(gè)Slave只能對(duì)應(yīng)一個(gè)Master。
每個(gè)Broker與Name Server集群中的所有節(jié)點(diǎn)建立長(zhǎng)連接，定時(shí)注冊(cè)Topic信息到所有Name Server。
Producer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)選擇）建立長(zhǎng)連接，定期從Name Server取Topic（消息的主題，也是消息的目的地）路由信息，并向提供Topic服務(wù)的Master建立長(zhǎng)連接，且定時(shí)向Master發(fā)送心跳。Producer完全無(wú)狀態(tài)，可集群部署。
Consumer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)選擇）建立長(zhǎng)連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master、Slave建立長(zhǎng)連接，且定時(shí)向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定。
二、消息生命周期介紹
對(duì)于任意一個(gè)消息中間件來(lái)說(shuō)，消息都需要經(jīng)過(guò)消息生產(chǎn)->消息存儲(chǔ)->消息消費(fèi)三個(gè)過(guò)程。其中消息生產(chǎn)包括了Producer端的消息構(gòu)造和消息發(fā)送，消息存儲(chǔ)包括了Broker端的消息接收和消息落地，消息消費(fèi)包括了Consumer端的消息接收和消息處理。不同消息中間件之所以功能不同，性能差異較大，其主要原因就是消息生命周期中各個(gè)階段的處理方式不同。在此簡(jiǎn)要介紹一下RocketMQ在各個(gè)階段的處理方式。
l 消息生產(chǎn)
消息的生產(chǎn)者Producer在發(fā)送消息時(shí)，會(huì)從Name Server上獲取消息的目的地（Topic）在各個(gè)Broker上的狀態(tài)，如果發(fā)現(xiàn)同一個(gè)Broker下的Topic有多個(gè)Queue（隊(duì)列），則會(huì)根據(jù)RoundBin算法依次向每個(gè)Queue發(fā)送消息，此外，如果發(fā)現(xiàn)多個(gè)Broker上均有相同Topic，也會(huì)依照輪詢的方式依次向這些Broker發(fā)送消息。
l 消息存儲(chǔ)
RocketMQ的消息存儲(chǔ)是由consume queue和commit log配合完成的。
consume queue是消息的邏輯隊(duì)列，相當(dāng)于字典的目錄，用于指定消息在物理文件commit log中的位置。每一個(gè)queue都有一個(gè)對(duì)應(yīng)的consume queue文件。consume queue中存放的是一串20字節(jié)定長(zhǎng)的二進(jìn)制數(shù)據(jù)，順序?qū)戫樞蜃x。
Commit Log是消息存放的物理文件，每臺(tái)Broker上的Commit Log被本機(jī)所有的queue共享，不做任何區(qū)分。CommitLog中消息存儲(chǔ)單元長(zhǎng)度不固定，文件順序?qū)懀S機(jī)讀。
簡(jiǎn)而言之，Broker端在收到一條消息后，如果是消息需要落盤，則會(huì)在Commit Log中寫入整條消息，并在consume queue中寫入該消息的索引信息。消息被消費(fèi)時(shí)，則根據(jù)consume queue中的信息去Commit Log中獲取消息。RocketMQ在消息被消費(fèi)后，并不會(huì)去Commit Log中刪除消息，而是會(huì)保存3天（可配置）而后批量刪除。
RocketMQ支持同步刷盤及異步刷盤兩種模式，同步刷盤指的是Producer將消息發(fā)送至Broker后，等待消息刷入Commit Log和consume queue后才算消息發(fā)送成功，而異步刷盤則是將消息發(fā)送至Broker后，Broker將消息放入內(nèi)存則告知Producer消息發(fā)送成功，而后由Broker自行將內(nèi)存中的消息批量刷入磁盤。
l 消息消費(fèi)
RocketMQ消息訂閱有兩種模式，一種是Push模式，即Broker主動(dòng)向消費(fèi)端推送；另外一種是Pull模式，即消費(fèi)端在需要時(shí)，主動(dòng)到Broker拉取。但在具體實(shí)現(xiàn)時(shí)，Push和Pull模式都是采用消費(fèi)端主動(dòng)拉取的方式。
Consumer端每隔一段時(shí)間主動(dòng)向broker發(fā)送拉消息請(qǐng)求，broker在收到Pull請(qǐng)求后，如果有消息就立即返回?cái)?shù)據(jù)，Consumer端收到返回的消息后，再回調(diào)消費(fèi)者設(shè)置的Listener方法。如果broker在收到Pull請(qǐng)求時(shí)，消息隊(duì)列里沒(méi)有數(shù)據(jù)，broker端會(huì)阻塞請(qǐng)求直到有數(shù)據(jù)傳遞或超時(shí)才返回。
與Kafka類似，Kafka中Consumer數(shù)量不能大于Partition數(shù)量，而在RocketMQ中Consumer的數(shù)量也不能大于隊(duì)列（Queue）的數(shù)量，如果Consumer超過(guò)隊(duì)列數(shù)量，那么多余的Consumer將不能消費(fèi)消息。可以簡(jiǎn)單理解為queue與consumer的關(guān)系是多對(duì)一的關(guān)系。
分析
我們基于公司網(wǎng)絡(luò)，搭建了RocketMQ的環(huán)境進(jìn)行測(cè)試。由于RocketMQ分為同步刷盤和異步刷盤兩種模式。不同的模式對(duì)性能的影響是巨大的，故我們考慮分別對(duì)同步刷盤和異步刷盤兩種模式進(jìn)行測(cè)試。本次測(cè)試設(shè)置2萬(wàn)條4K字節(jié)的消息為一組，測(cè)試10組（20萬(wàn)條消息），然后取平均值。搭建的服務(wù)器為SuseLinux 11 SP4，4C8G。
案例一：1生產(chǎn)者發(fā)送2W條4K字節(jié)消息，異步刷盤
TPS: 1204.964454
案例二：1生產(chǎn)者發(fā)送2W條4K字節(jié)消息，同步刷盤
TPS: 181.9604418
可以看到，同步刷盤和異步刷盤，對(duì)性能的影響幾乎是10倍計(jì)。
此外，在測(cè)試中發(fā)現(xiàn)，單個(gè)生產(chǎn)者的線程數(shù)量對(duì)消息的生產(chǎn)速度也有很大的影響。
同樣的，也可以得到異步刷盤模式下TPS與線程數(shù)量的關(guān)系，可以看到，在線程數(shù)達(dá)到16個(gè)以后，再增加線程數(shù)，對(duì)TPS的提升也不大，可以判斷此時(shí)其他因素影響了TPS的提升。
而對(duì)于消息的消費(fèi)來(lái)說(shuō)，由于RocketMQ會(huì)將消息在內(nèi)存中保存一份，因此消息的消費(fèi)并不受是否持久化影響。如果是及時(shí)消費(fèi)，那么消息的消費(fèi)速度是極快的。
案例三：1消費(fèi)者消費(fèi)2W條4K字節(jié)消息
TPS: 17825.31194
從性能方面來(lái)看，消息的生產(chǎn)速度低于消息的消費(fèi)速度，這可以基本保證不會(huì)出現(xiàn)消息堆積的場(chǎng)景。且如果出現(xiàn)了消息堆積，RocketMQ由于其消息的存儲(chǔ)架構(gòu)，也不會(huì)像其他MQ一樣出現(xiàn)消息堵塞的問(wèn)題。
而從RocketMQ的原理及部署架構(gòu)來(lái)看，其主要適用的場(chǎng)景為分布式系統(tǒng)下海量消息的消峰填谷，由于其部署架構(gòu)包含了NameServer和Broker兩種形式，因此對(duì)于較小的分布式系統(tǒng)來(lái)說(shuō)，搭建和運(yùn)維并不方便。
建議
相比業(yè)界比較成熟的MQ來(lái)說(shuō)，RocketMQ由于是阿里部分開源的產(chǎn)品，其成熟度及社區(qū)活躍度不如Kafka，ActiveMQ，RabbitMQ等業(yè)界主流消息中間件。但是由于RocketMQ采用Java實(shí)現(xiàn)（Kafka使用scala語(yǔ)言），其主要功能的源碼可以進(jìn)行二次開發(fā)進(jìn)行改造。因此若公司需要掌握一門開源中間件的技術(shù)，對(duì)RocketMQ進(jìn)行深入研究是有價(jià)值的。
綜合來(lái)看，RocketMQ有優(yōu)點(diǎn)也有缺點(diǎn)，建議：
1、對(duì)于小規(guī)模的分布式系統(tǒng)之間需要用到消息中間件的場(chǎng)景，可以仍然采用IBM MQ或ActiveMQ等部署運(yùn)維較為簡(jiǎn)單的開源消息中間件來(lái)實(shí)現(xiàn)。
2、對(duì)于大型的分布式系統(tǒng)，可以考慮使用RocketMQ進(jìn)行數(shù)據(jù)交互，但由于RocketMQ目前的開源版本不支持主備自動(dòng)切換，因此在高可用方面需要進(jìn)行深入的研究，必要時(shí)需要進(jìn)行二次開發(fā)。
3、RocketMQ就性能來(lái)說(shuō)，強(qiáng)于ActiveMQ，就可讀性及消息交互功能來(lái)說(shuō)，強(qiáng)于Kafka，實(shí)際業(yè)務(wù)可根據(jù)具體需要進(jìn)行選型。
4、后續(xù)可繼續(xù)深入研究RocketMQ，并總結(jié)出各關(guān)鍵技術(shù)（如消息的存儲(chǔ)，集群設(shè)計(jì)，主備復(fù)制等）和設(shè)計(jì)思路，豐富技術(shù)儲(chǔ)備。
