文章深度解讀了某商業(yè)銀行做消息隊(duì)列選型時(shí)考慮的因素，包括關(guān)鍵需求、選型要點(diǎn)、選型原則等，同時(shí)給出了選型建議、產(chǎn)品對(duì)比以及典型場(chǎng)景和二次封裝的建議。本文作者在自己豐富實(shí)踐經(jīng)驗(yàn)基礎(chǔ)上抽象出一些方法論，供讀者在做消息隊(duì)列技術(shù)選型時(shí)參考。

本文主要內(nèi)容包括以下方面：

1 概述

2 為什么引入消息隊(duì)列

•   何為消息隊(duì)列

•   消息隊(duì)列的優(yōu)勢(shì)

•   消息隊(duì)列的不足 

3 消息隊(duì)列選型

•    關(guān)鍵需求

•   其他需要考慮的因素

•   選型要點(diǎn)及原則

•   選型建議

•   候選產(chǎn)品比較

•   選擇RocketMQ的原因

 4 二次封裝建議

 5 典型場(chǎng)景

•     支付場(chǎng)景

•    第三方延時(shí)調(diào)用場(chǎng)景

6 經(jīng)驗(yàn)總結(jié)和建議

作為金融企業(yè)對(duì)公眾提供服務(wù)一定要保證其可用性，盡量做到更多個(gè)9（一般SLA中描述的高可用性99.99%，中的9越多代表全年服務(wù)可用時(shí)間越長(zhǎng)服務(wù)更可靠，停機(jī)時(shí)間越短），隨著軟件系統(tǒng)的復(fù)雜度越來(lái)越高，故障是不可避免的。這就需要企業(yè)實(shí)現(xiàn)整體的彈性架構(gòu)（Resilient Architecture），為應(yīng)對(duì)故障而設(shè)計(jì)。

然而，常見(jiàn)的RPC、RMI企業(yè)集成技術(shù)，因?yàn)槭峭秸?qǐng)求，常因?yàn)閳?zhí)行方失敗、超時(shí)等因素而影響最終用戶(hù)體驗(yàn)，而且很多故障是無(wú)法徹底消除的。而且RPC和RMI調(diào)用需要服務(wù)的消費(fèi)方和服務(wù)的提供方同時(shí)在線(xiàn)，并且雙方需要通過(guò)某種機(jī)制確認(rèn)彼此的調(diào)用關(guān)系，因?yàn)榇嬖谶@些弊端，就導(dǎo)致了面向消息的中間件（MOM）的產(chǎn)生，通過(guò)在企業(yè)架構(gòu)中引入消息中間件，確保在故障發(fā)生時(shí)，受此影響的系統(tǒng)部分在一個(gè)很小的范圍內(nèi)。

消息中間件就是在分布式系統(tǒng)中間引入一個(gè)透明的中間層，隔離服務(wù)的提供方和消費(fèi)方。

2.1 何為消息隊(duì)列

消息隊(duì)列（Message Queue，MQ）是一種不同應(yīng)用程序之間(跨進(jìn)程)的通信方法，用于上下游應(yīng)用程序之間傳遞消息。我們拆分來(lái)看：

• 消息：應(yīng)用程序通過(guò)寫(xiě)入和檢索出入列隊(duì)的數(shù)據(jù)（消息）來(lái)通信。

• 隊(duì)列：除去了接收和發(fā)送應(yīng)用程序同時(shí)執(zhí)行的要求。

這樣就實(shí)現(xiàn)了上游與下游之間的解耦，上游向MQ發(fā)送消息，下游從MQ接收消息，上游下游互不依賴(lài)，它們只依賴(lài)MQ。因?yàn)橛嘘?duì)列的存在，MQ可在上下游之間進(jìn)行緩沖，把上游信息先緩存起來(lái)，下游根據(jù)自己的能力從MQ中拉取信息，起到削峰的作用。

2.2 消息隊(duì)列的優(yōu)勢(shì)

1   解耦

1）什么是耦合

高內(nèi)聚低耦合，是軟件工程中的概念，這里的低耦合是指各個(gè)組件之間，盡可能相互獨(dú)立。通俗一點(diǎn)的理解就是，增加模塊間調(diào)用透明化，最高的透明度就是不用知道彼此的存在，因此減少接口的復(fù)雜性、規(guī)范調(diào)用的方式及傳遞的信息，降低產(chǎn)品各模塊的依賴(lài)，提高重用程度。

2）如何解耦

在企業(yè)整體架構(gòu)中解耦，主要設(shè)計(jì)兩個(gè)方面：一是簡(jiǎn)化減少交互，二是增加一個(gè)中間層實(shí)現(xiàn)兩方的隔離，MQ就是其中的中間層（如下圖所示）。引入MQ后生產(chǎn)者和消費(fèi)者不必知道彼此的存在也不必同時(shí)在線(xiàn)，主要交互流程如下：

• 生產(chǎn)者負(fù)責(zé)：生產(chǎn)消息并通過(guò)SDK或API調(diào)用發(fā)送給MQ（同步發(fā)送或者異步發(fā)送）；

• MQ負(fù)責(zé)：接收消息，并持久化消息到消息存儲(chǔ)（同步或異步存儲(chǔ)消息）；

• 生產(chǎn)者接收來(lái)自MQ的響應(yīng)（消息發(fā)送狀態(tài)或異常）；

• 消費(fèi)者訂閱消息后，接收來(lái)自MQ的消息；

• 消費(fèi)者執(zhí)行消息對(duì)應(yīng)的后續(xù)業(yè)務(wù)操作；

• 對(duì)消費(fèi)結(jié)果進(jìn)行確認(rèn)（消費(fèi)成功、失敗、異常等）。

• 削峰填谷

2 削峰填谷

由于系統(tǒng)閑忙分布不均，QPS常相差幾十倍甚至更高，特別是在遇到營(yíng)銷(xiāo)活動(dòng)時(shí)，瞬間流量很可能超過(guò)后端系統(tǒng)的承載能力，這就要考慮通過(guò)消息中間件來(lái)緩沖，MQ客戶(hù)端實(shí)例根據(jù)自己的處理能力從MQ服務(wù)器拉取消息，以此來(lái)減輕或消除后端系統(tǒng)的瓶頸。

（圖片來(lái)源：https://github.com/alibaba/Sentinel/wiki/Sentinel-為-RocketMQ-保駕護(hù)航）

3 異構(gòu)集成

由于各種原因，我們?cè)谄髽I(yè)信息化建設(shè)過(guò)程中，都會(huì)面臨軟件產(chǎn)品來(lái)自不同的廠(chǎng)家只解決某特定領(lǐng)域的問(wèn)題，這些產(chǎn)品因?yàn)榉忾]的架構(gòu)無(wú)法對(duì)外提供服務(wù)或缺少核心開(kāi)發(fā)而無(wú)法做大的改造，這就造成了彼此之間很難集成。通過(guò)引入MQ可以部分解決該問(wèn)題，只需要在某個(gè)環(huán)節(jié)生產(chǎn)一條消息，或者根據(jù)消息做出具體的響應(yīng)，只需與MQ對(duì)接，不必與其他系統(tǒng)做一對(duì)一的對(duì)接。

4 異步隔離

為了提供金融服務(wù)的整體彈性，需要隔離內(nèi)部、外部系統(tǒng)間的依賴(lài)。如支付通知分為兩種，一種是同步通知，這時(shí)API調(diào)用會(huì)因?yàn)榫W(wǎng)絡(luò)故障而超時(shí)，因?yàn)榉?wù)提供方處理能力限制而得不到及時(shí)響應(yīng)等多種因素影響，另一種是異步通知，在一定時(shí)效范圍內(nèi)最終通知到即可，從而提供提高最終用戶(hù)的體驗(yàn)和交易成功率，提高業(yè)務(wù)的整體生產(chǎn)率。

2.3 消息隊(duì)列的不足

凡有收益必有代價(jià)，MQ也有其不足：

• 在支持靈活性的同時(shí)，增加了系統(tǒng)的整體復(fù)雜度。

• 因?yàn)楫惒秸{(diào)用的延時(shí)大于RPC同步調(diào)用是，所以會(huì)出現(xiàn)短暫的不一致性

• 無(wú)法做到事務(wù)的強(qiáng)一致，需要分布式事務(wù)方案來(lái)處理

• 服務(wù)的消費(fèi)方要做冪等設(shè)計(jì)，來(lái)規(guī)避重復(fù)調(diào)用的問(wèn)題

所以在軟件的正常功能開(kāi)發(fā)中，并不需要去刻意的尋找消息隊(duì)列的使用場(chǎng)景，而是當(dāng)出現(xiàn)性能瓶頸時(shí)，去查看業(yè)務(wù)邏輯是否存在可以異步處理的耗時(shí)操作，如果存在的話(huà)便可以引入消息隊(duì)列來(lái)解決。否則盲目的使用消息隊(duì)列可能會(huì)增加維護(hù)和開(kāi)發(fā)的成本卻無(wú)法得到可觀(guān)的性能提升，那就得不償失了。

但凡選擇就會(huì)受到主觀(guān)和客觀(guān)兩個(gè)因素的影響。我們?nèi)绾伪M量客觀(guān)的進(jìn)行架構(gòu)和框架選型，而避免先有結(jié)果而后找理由的文字游戲，下面我分享下我們做MQ選型的過(guò)程（這里不是說(shuō)主觀(guān)就是不好的，但作為工程師凡事做結(jié)構(gòu)化和量化還是有必要的）。

3.1 關(guān)鍵需求

•  集群支持：為了保證消息中間件的可靠性，需要提供完備的生產(chǎn)者、消費(fèi)者、消息中間件集群方案；

• 持久化的支持：為了避免消息丟失，需要支持消息保存到磁盤(pán)文件或其它格式存儲(chǔ)；

• 消息重試的支持：消息處理失敗后的支持失敗轉(zhuǎn)存或重試，并提供消息至少投第一次或消息最多投遞一次的配置；

• 分布式事務(wù)的支持：為了保證業(yè)務(wù)的完整性，選擇的中間件需要支持分布式；

• 消息的按序消費(fèi)：在有些場(chǎng)景下，需要消息的消費(fèi)能夠按照發(fā)送的同樣順序進(jìn)行處理從而保證順序執(zhí)行；

• 消息的延時(shí)支持：在2C業(yè)務(wù)處理或三方數(shù)據(jù)源對(duì)接中，會(huì)遇到消息延時(shí)投遞要求，需要支持延投遞；

• 消息堆積和回溯功能：在消息中間件持久化保存大量消息時(shí)不會(huì)對(duì)性能有大的影響，支持消息查詢(xún)、重發(fā)，或者按照時(shí)間點(diǎn)來(lái)重新消費(fèi)消息，以應(yīng)對(duì)某一段時(shí)間消息的重新消費(fèi)場(chǎng)景。

3.2 其他需要考慮的因素

• 產(chǎn)品與當(dāng)前技術(shù)棧是否匹配，團(tuán)隊(duì)人員熟悉源代碼更便于對(duì)消息中間件的原理理解和后續(xù)功能擴(kuò)展；

•  產(chǎn)品的使用廣度特別是金融同業(yè)客戶(hù)：同業(yè)因?yàn)闃I(yè)務(wù)同質(zhì)化校對(duì)，場(chǎng)景需求相近，使用的人越多，說(shuō)明關(guān)鍵場(chǎng)景支持較好，問(wèn)題在之前暴露的越充分，當(dāng)我們?cè)谑褂脮r(shí)碰問(wèn)題的時(shí)候，就比較容易找到對(duì)應(yīng)的解決方案或解決人員；

• 產(chǎn)品的高可用性：作為一個(gè)金融企業(yè)，需要服務(wù)的持續(xù)可用，作為提高企業(yè)彈性的基礎(chǔ)消息平臺(tái)，集群和高可用是一個(gè)必不可少的要求；

• 產(chǎn)品的穩(wěn)定性：產(chǎn)品可以持續(xù)、穩(wěn)定的提供服務(wù)，不需要經(jīng)常因?yàn)橘Y源泄露或性能衰減等問(wèn)題而重新啟動(dòng)。

• 產(chǎn)品的活躍度：通過(guò)github統(tǒng)計(jì)數(shù)據(jù)能看出來(lái)這個(gè)產(chǎn)品是否經(jīng)常有人維護(hù)，經(jīng)常有人開(kāi)發(fā)一些新的功能，經(jīng)常fix一些bug。

3.3 選型要點(diǎn)及原則

• 搜尋滿(mǎn)足關(guān)鍵需求的框架到候選清單；

• 從功能和非功能性需求等幾個(gè)方面對(duì)候選框架進(jìn)行篩選；

• 在選型過(guò)程中要做好量化記錄，避免先有傾向性的結(jié)果，后有篩選，這樣選型就變成了一場(chǎng)數(shù)字游戲；

• 有時(shí)要換個(gè)角度思考，常用來(lái)做比較的可能就是最好的，如很多MQ框架都與Kafka做比較，那么Kafka有可能就是最通用的框架，如果做選型就要對(duì)其是否滿(mǎn)足自己的需求做重點(diǎn)分析；

• 遵循第三眼美女原則，讓理性引導(dǎo)感性；

  適合的就是最好的，不要但純追求高性能和功能全面。

3.4 選型建議

     為未來(lái)最少三年或五到十年來(lái)選擇，因?yàn)門(mén)edNeward在JAVA 消息服務(wù)的序言中總結(jié)了技術(shù)熟悉的過(guò)程4個(gè)階段（門(mén)外漢、探索者、熟手、大師）。選型到全范圍推廣結(jié)束一年左右的時(shí)間就過(guò)去了，到大家熟悉和精通又一年過(guò)去了，誰(shuí)都不想在剛熟悉還沒(méi)用好，當(dāng)前的產(chǎn)品就不滿(mǎn)足要求了，又要重新來(lái)過(guò)。

區(qū)分關(guān)注點(diǎn)，確保只針對(duì)核心關(guān)注點(diǎn)進(jìn)行選擇。給出選擇的deadline，并按時(shí)進(jìn)入到項(xiàng)目實(shí)戰(zhàn)準(zhǔn)備，再多的理論分析，都不如真正使用過(guò)后的感受深入，產(chǎn)品需要成長(zhǎng)、團(tuán)隊(duì)成員同樣需要成長(zhǎng)，既然路在遠(yuǎn)方就趕緊起程。

3.5 候選產(chǎn)品比較

1 產(chǎn)品特性比較

2 測(cè)試建議

     功能測(cè)試：建議搭建POC環(huán)境進(jìn)行驗(yàn)證，除驗(yàn)證相關(guān)功能性指標(biāo)有沒(méi)有，還要驗(yàn)證好不好用。所以在測(cè)試時(shí)要基于MQ提供的功能構(gòu)建使用場(chǎng)景進(jìn)行業(yè)務(wù)功能實(shí)現(xiàn)的驗(yàn)證。

性能測(cè)試：其實(shí)性能測(cè)試涉及的各方面因素比較多，如：基于什么樣的環(huán)境，做了哪些配置，采用什么樣的壓測(cè)腳本和報(bào)文來(lái)做壓力測(cè)試？比較指標(biāo)：除TPS（發(fā)送者TPS、消費(fèi)者最終處理業(yè)務(wù)的TPS）、延時(shí)、支持多少同時(shí)在線(xiàn)鏈接（生產(chǎn)者數(shù)據(jù)量、消費(fèi)者數(shù)據(jù)量）、Topic配置（Topic數(shù)量以及每個(gè)Topic隊(duì)列數(shù)量與生產(chǎn)者、消費(fèi)者數(shù)據(jù)量的關(guān)系）、服務(wù)器的性能指標(biāo)（cpu、內(nèi)存、磁盤(pán)io、網(wǎng)絡(luò)io）如何等也是需要考量的。

疲勞測(cè)試：在一定壓力下持續(xù)運(yùn)行24小時(shí)、一周或更長(zhǎng)時(shí)間。要重點(diǎn)關(guān)注穩(wěn)定性、服務(wù)器的各項(xiàng)指標(biāo)、是否有緩慢增長(zhǎng)的趨勢(shì)等。

重啟或故障演練：分別對(duì)注冊(cè)中心NameServer、Broker、Producer、Consumer的實(shí)例進(jìn)行部分重啟（或直接kill）或全部重啟（或直接kill）、磁盤(pán)故障、網(wǎng)絡(luò)故障等，查看應(yīng)用的影響，如：在RocketMQ服務(wù)是否可以恢復(fù)，生產(chǎn)者消費(fèi)者是否可以恢復(fù)服務(wù)，消息是否有丟失，消息是否有重復(fù)等。

3.6 選擇RocketMQ的原因

• ActiveMQ的優(yōu)勢(shì)在于支持協(xié)議多樣、文檔資料豐富，缺點(diǎn)是性能、順序投遞支持有限；

• Kafka的優(yōu)勢(shì)在于高吞吐率，缺點(diǎn)是分布式事務(wù)、消費(fèi)失敗重試、延時(shí)/定時(shí)消息支持有限；

• RabbitMQ的優(yōu)勢(shì)在于與SpringBoot集成好，缺點(diǎn)是分布式事務(wù)、延時(shí)/定時(shí)消息支持有限；

• RockeMQ的優(yōu)勢(shì)在于高吞吐率、順序消息、延時(shí)消息、消息堆積、消息回溯等支持較好，缺點(diǎn)是支持協(xié)議有限，多語(yǔ)言客戶(hù)端支持有限。

我們最終選擇RocketMQ的主要原因如下：

• 金融服務(wù)有場(chǎng)景對(duì)順序消息有嚴(yán)格要求；

• 金融服務(wù)有場(chǎng)景對(duì)延時(shí)消息需求；

• 為了保證最終一致性需要支持分布式事務(wù)；

• 為了保證一致性消息對(duì)賬需要MQ中間件支持消息查詢(xún)；

• RocketMQ在高一致性（持久化、消息重試）做的比較好；

• 行內(nèi)使用的JAVA技術(shù)棧，暫不需要多協(xié)議和多語(yǔ)言支持；

• RocketMQ的用戶(hù)有國(guó)內(nèi)知名的互聯(lián)網(wǎng)金融公司、有微眾銀行、民生銀行這樣的互聯(lián)銀行和直銷(xiāo)銀行代表、有企業(yè)軟件服務(wù)商，從3.1選型需求匹配和主要用戶(hù)可以看出RocketMQ對(duì)金融場(chǎng)景適配比較好行業(yè)認(rèn)可度高，隨著金融用戶(hù)的使用未來(lái)更多的需求將會(huì)被滿(mǎn)足。

封裝主要是對(duì)業(yè)務(wù)、技術(shù)和數(shù)據(jù)進(jìn)行抽象和封裝，封裝具有如下優(yōu)點(diǎn)：

• 透明，通過(guò)引入二次封裝SDK膠水層，隱藏具體實(shí)現(xiàn)細(xì)節(jié)

• 重用，提高基礎(chǔ)代碼的重用性同時(shí)增加的代碼的可維護(hù)性和可靠性

• 安全，通過(guò)規(guī)范操作提高安全性

將規(guī)范封裝到基礎(chǔ)代碼中以便在企業(yè)內(nèi)部統(tǒng)一交互標(biāo)準(zhǔn)，具體的規(guī)范包括：

• topic命名規(guī)范

• producter命名規(guī)范

• Consumer命名規(guī)范

• 基于MessageId、key或業(yè)務(wù)ID的冪等通用方案封裝

通過(guò)賦義編碼規(guī)范可以通過(guò)名稱(chēng)定位到所屬項(xiàng)目、模塊等業(yè)務(wù)場(chǎng)景，以便在出現(xiàn)未知問(wèn)題時(shí)可以快速協(xié)調(diào)人員進(jìn)行處理，當(dāng)然對(duì)topic、生產(chǎn)者、消費(fèi)者等原數(shù)據(jù)管理也是必要的，畢竟命名規(guī)范能保留的信息有限。通過(guò)命名規(guī)范還可以避免沖突，比如topic的沖突會(huì)或誤會(huì)導(dǎo)致消息無(wú)法正常消費(fèi)或者業(yè)務(wù)流轉(zhuǎn)等問(wèn)題，消費(fèi)者GroupID沖突會(huì)導(dǎo)致消息丟失等問(wèn)題。

通過(guò)封裝和定制化增強(qiáng)管理功能如批量信息查詢(xún)、批量信息重發(fā)、消息對(duì)賬等。

RocketMQ是提高整體服務(wù)彈性的重要基礎(chǔ)中間件，在個(gè)類(lèi)金融交易中承擔(dān)著重要的角色。

4.1 支付場(chǎng)景

下面以活期賬戶(hù)轉(zhuǎn)出服務(wù)場(chǎng)景為例來(lái)講解。

• 出于安全考慮我們每筆用戶(hù)活期賬戶(hù)轉(zhuǎn)出都要發(fā)送一條短信通知，這時(shí)通過(guò)RPC調(diào)用即可實(shí)現(xiàn)，如下圖所示：

• 隨著業(yè)務(wù)發(fā)展及出于安全和反欺詐考慮，建設(shè)了反欺詐服務(wù)，需要在每筆轉(zhuǎn)出時(shí)發(fā)送支出場(chǎng)景的埋點(diǎn)數(shù)據(jù)，這個(gè)時(shí)候有兩種方案，一種是繼續(xù)使用RPC調(diào)用，如下圖所示，這時(shí)轉(zhuǎn)出操作響應(yīng)時(shí)間可能是處理耗時(shí)A 短信調(diào)用時(shí)間B 反欺詐服務(wù)調(diào)用時(shí)間C（也有可能是通過(guò)異步RPC調(diào)用：響應(yīng)時(shí)間轉(zhuǎn)出操作時(shí)間 Max（B，C）），除了耗時(shí)之外，系統(tǒng)的故障點(diǎn)也多了，如果反欺詐服務(wù)或者短信服務(wù)宕機(jī)了，那么很大可能活期賬戶(hù)轉(zhuǎn)出服務(wù)會(huì)隨之宕掉（如果使用了熔斷和隔離，可以很大程度規(guī)避跨系統(tǒng)間的調(diào)用異常影響）。

• 第二種解決方案是未雨綢繆，既然現(xiàn)在有第二個(gè)服務(wù)需要了解事件，那么以后是不是還會(huì)有第三個(gè)、第N個(gè)呢？如下圖所示。這時(shí)活期賬戶(hù)轉(zhuǎn)出服務(wù)的穩(wěn)定性會(huì)進(jìn)一步降低，復(fù)雜度急劇上升，在處理登錄邏輯的同時(shí)需要考慮N個(gè)系統(tǒng)的關(guān)聯(lián)需求。

• 如果從領(lǐng)域模型上看這些是活期賬戶(hù)轉(zhuǎn)出服務(wù)應(yīng)該做的嗎？顯然不是，轉(zhuǎn)出應(yīng)該只關(guān)注與本身的賬戶(hù)操作，其它服務(wù)應(yīng)該依賴(lài)轉(zhuǎn)出的事件來(lái)做后續(xù)的相關(guān)業(yè)務(wù)邏輯，在這樣的場(chǎng)景中適合用消息中間件來(lái)解耦。如下圖所示。

這樣各服務(wù)回歸到本來(lái)應(yīng)該的樣子，賬戶(hù)轉(zhuǎn)出服務(wù)不用關(guān)注于其它系統(tǒng)對(duì)它的依賴(lài)，只需要產(chǎn)生賬戶(hù)轉(zhuǎn)出事件的消息，有需要的服務(wù)各自去訂閱這個(gè)消息就好了，相互不受影響。

4.2 第三方延時(shí)調(diào)用場(chǎng)景

在與銀行外部系統(tǒng)對(duì)接的時(shí)候，會(huì)有需要在發(fā)送服務(wù)請(qǐng)求N秒后，去獲得響應(yīng)結(jié)果的異步請(qǐng)求。在使用RocketMQ的延時(shí)消息前，都是通過(guò)將數(shù)據(jù)落地到數(shù)據(jù)庫(kù)或Redis緩存中，然后通過(guò)定時(shí)輪詢(xún)?nèi)蝿?wù)來(lái)操作。這樣做有以下缺點(diǎn)：

• 非通用方案，每個(gè)系統(tǒng)都需要單獨(dú)維護(hù)一個(gè)輪詢(xún)?nèi)蝿?wù)；

• 數(shù)據(jù)量大了以后輪詢(xún)會(huì)影響數(shù)據(jù)庫(kù)性能；

• 輪詢(xún)時(shí)間不宜設(shè)置過(guò)低，常以分鐘為單位輪詢(xún)，時(shí)效性差，如果時(shí)間過(guò)短對(duì)數(shù)據(jù)庫(kù)壓力也會(huì)增加；

• 針對(duì)輪詢(xún)失敗的重試機(jī)制需要各自實(shí)現(xiàn)。

使用RocketMQ后有以下優(yōu)點(diǎn)：

• 通用延時(shí)方案，生產(chǎn)延時(shí)消息和消息消費(fèi)隔離；

• 支持高并發(fā)，具備較好的橫向擴(kuò)展能力；

• 時(shí)效性大幅提升，可以精確到秒級(jí)。

不過(guò)，當(dāng)前版本還不支設(shè)置時(shí)間精度，只能按照特定的messageDelayLevel來(lái)設(shè)置，這就要在搭建RocketMQ時(shí)提前最好延時(shí)級(jí)別的規(guī)劃或者對(duì)RocketMQ延時(shí)源碼進(jìn)行擴(kuò)展以支持指定時(shí)間精度。

• Topic隊(duì)列數(shù)設(shè)置不合理導(dǎo)致負(fù)載不均衡，影響RocketMQ的Broker的穩(wěn)定。

• 消息堆積導(dǎo)致投遞延時(shí)時(shí)間變長(zhǎng)。

• 因?yàn)橄M(fèi)者的集群ID設(shè)置不規(guī)范，導(dǎo)致A消費(fèi)者消費(fèi)了B的消息。

• 因?yàn)門(mén)opic設(shè)置的不合理導(dǎo)致一個(gè)Broker節(jié)點(diǎn)的宕機(jī)導(dǎo)致消息消投遞和消費(fèi)異常。

• Topic、消費(fèi)者GroupID相關(guān)命名不規(guī)范，導(dǎo)致運(yùn)行一段時(shí)間后RocketMQ的Topic混亂無(wú)法清理回收資源。

當(dāng)故障是不可避免的，就需要在應(yīng)用程序設(shè)計(jì)的時(shí)候考慮通過(guò)一系列機(jī)制具備自我管理、自我恢復(fù)、自我配置等自治功能，隨著云原生架構(gòu)的流行，面對(duì)負(fù)載的加重和不斷發(fā)生的各類(lèi)故障，MQ不會(huì)是彈性系統(tǒng)設(shè)計(jì)的唯一選擇，但也許是一個(gè)不錯(cuò)的選擇，值得一試。

聲明：文章謹(jǐn)代表作者觀(guān)點(diǎn)，與所在平臺(tái)無(wú)關(guān)。