1   背景

<i id='Id7g4'></i>

目前天翼云已支持Kafka、RocketMQ、RabbitMQ、MQTT四款款主流的消(xiao)息中間產(chan)品，用(yong)戶需(xu)要根據用(yong)途(tu)選擇合適產(chan)品。

2   目標

主流的(de)消息(xi)中(zhong)間(jian)件(jian)有Kafka、RocketMQ、RabbitMQ、MQTT、PULSAR等多款組件(jian)，本文列舉(ju)了一些(xie)選型指標，為用戶消息(xi)選型提供(gong)方向(xiang)。

2.1    總體目標

分析消息(xi)引擎(qing)的主要(yao)目標是增強天(tian)翼云的消息(xi)中間件(jian)產(chan)品(pin)服務能力，豐富產(chan)品(pin)類型、縮(suo)小與頭部(bu)云廠商的差距。

2.2 選型目標

從(cong)架(jia)構(gou)、消息服(fu)務能力、性(xing)能、可(ke)靠(kao)性(xing)、可(ke)用性(xing)、擴展性(xing)、社區、生(sheng)態(tai)等多維度對，對主流消息中(zhong)間件(jian)進行分析，選擇合適的消息中(zhong)間件(jian)，匹配用戶生(sheng)產需求(qiu)。

3   消息中間件概述

3.1 消息中間件特性

 消息(xi)中(zhong)間件(MQ)在當前的分布式系統架(jia)構(gou)中(zhong)承載(zai)著重(zhong)要的作用，其核心(xin)的應用場景主要有以下三個：

異步，異步調用(yong)為非阻塞模式，延遲(chi)低，對(dui)于一些耗時的場景(jing)，比如訂單完成后，實現短信或郵(you)件通知，就適合采用(yong)消息分發機制。

解耦，消(xiao)(xiao)息(xi)系(xi)統采用生(sheng)產(chan)訂閱模式，生(sheng)產(chan)者只(zhi)負(fu)責將消(xiao)(xiao)息(xi)發(fa)送出去，而不關心誰來消(xiao)(xiao)費；消(xiao)(xiao)費者只(zhi)負(fu)責獲取(qu)并處理消(xiao)(xiao)息(xi)，而不用關心誰生(sheng)產(chan)的，生(sheng)產(chan)和(he)消(xiao)(xiao)費系(xi)統的解耦，對于大型(xing)復雜的業務系(xi)統尤其重要，微服務的理念也是(shi)如(ru)此(ci)。

削峰，在(zai)高并發的場景下，通過消(xiao)費(fei)系統的延遲(chi)消(xiao)費(fei)，大大緩解服務(wu)器的壓(ya)力，典型就是(shi)電商雙十一(yi)的場景，瞬間(jian)產生海量消(xiao)息，通過MQ的消(xiao)息堆積能(neng)(neng)力，將(jiang)消(xiao)費(fei)端處理(li)能(neng)(neng)力控制在(zai)合理(li)的范圍內(nei)。

3.2 消息中間件類型

消費中間件(jian)有很多種(zhong)，目前(qian)主流的(de)主要以(yi)下四款產品，分別為RabbitMQ，Kafka，RocketMQ，Pulsar。

3.2.1 Kafka

     Kafka是(shi)由Apache軟件基金會(hui)開(kai)發的(de)(de)一個開(kai)源流處(chu)理平臺，由Scala和Java編寫(xie)。在MQ家族比較另類，它其(qi)實也(ye)是(shi)大數(shu)據家族的(de)(de)重(zhong)要成(cheng)員，設(she)計(ji)之(zhi)初就(jiu)具備了高吞吐(tu)(tu)的(de)(de)特性，是(shi)一種高吞吐(tu)(tu)量(liang)的(de)(de)分布式發布訂閱消息系統。

    現代互聯網大(da)(da)數(shu)據(ju)中(zhong)，如需(xu)要分析用戶(hu)的特性，愛好，習慣等(deng)，就需(xu)要收(shou)集海量的用戶(hu)行(xing)為(wei)數(shu)據(ju)，包括瀏覽路(lu)徑，點擊動作(zuo)，行(xing)為(wei)日志(zhi)等(deng)等(deng)，這些海量的數(shu)據(ju)的傳遞和匯聚(ju)可以通(tong)過Kafka完(wan)成，如其說Kafka是消息中(zhong)間件(jian)系統，不如說是大(da)(da)數(shu)據(ju)交換通(tong)道(dao)系統，所(suo)以Kafka定位為(wei)流處理平(ping)臺。

3.2.2 RocketMQ

      Rocket是由阿里巴巴開發(fa)，是為數(shu)不多(duo)的(de)由國(guo)人開發(fa)，貢獻給(gei)Apache組織的(de)項(xiang)目，其采(cai)用Java語(yu)言開發(fa)。經(jing)過阿里歷年雙十(shi)一流量洪峰的(de)洗禮，并(bing)發(fa)性和可靠性得到了充分的(de)驗(yan)證(zheng)，且支持(chi)的(de)功(gong)能豐(feng)富，是活躍度(du)較高的(de)中間件之一，由于中文文檔豐(feng)富，又有(you)(you)阿里巴巴支撐，在國(guo)內很有(you)(you)市(shi)場。

3.2.3 Pulsar

         Pulsar是(shi)由yahoo公司于2016年(nian)開(kai)(kai)源，2018年(nian)成為(wei)(wei)Apache的頂級項目，被譽為(wei)(wei)下一代的消(xiao)息隊列，業界(jie)對(dui)其(qi)期望很高。Pulsar采用Java開(kai)(kai)發，使用Bookeeper作為(wei)(wei)存(cun)儲，具備了高吞吐(tu)，低延遲，計(ji)算(suan)存(cun)儲分離，多(duo)租(zu)戶，異(yi)地復制(zhi)等特(te)性，這些(xie)特(te)性也(ye)(ye)使得(de)Pulsar成為(wei)(wei)Kafka的有力競爭者，實際上，它也(ye)(ye)是(shi)對(dui)標(biao)Kafka的產品(pin)。

       Pulsar作為(wei)后起之秀，并(bing)沒(mei)有Kafka為(wei)人熟(shu)知，但(dan)是近些年(nian)國內的一些大(da)的互聯網(wang)企業(ye)也逐(zhu)漸(jian)關注(zhu)，并(bing)在生產(chan)系統上線，比如騰(teng)迅(xun)的的計費系統、云(yun)消息產(chan)品TDMQ。

3.2.4 RabbitMQ

       RabbitMQ是(shi)采用(yong)Erlang語言(yan)實(shi)(shi)現(xian)AMQP(Advanced Message Queuing Protocol，高級(ji)消息(xi)隊列協議(yi))。AMQP是(shi)一個應(ying)用(yong)層協議(yi)的(de)開(kai)放(fang)標(biao)準(zhun)，解決消息(xi)中間(jian)件(jian)的(de)需(xu)求和拓(tuo)撲問(wen)題(ti)。RabbitMQ也是(shi)該協議(yi)最成功的(de)產品實(shi)(shi)現(xian)。Erlang語言(yan)其實(shi)(shi)是(shi)比較小眾的(de)，最初用(yong)于交換機領(ling)域(yu)的(de)架(jia)構(gou)模式(shi)，被用(yong)來實(shi)(shi)現(xian)AMQP協議(yi)，使得(de)RabbitMQ在Broker之間(jian)進行數據交互的(de)性(xing)能非常(chang)優秀。RabbitMQ以其可靠性(xing)，靈(ling)活路(lu)由，以及強大(da)的(de)集群模式(shi)，在MQ家(jia)族中大(da)放(fang)異彩。

4   消息中間件選型

消(xiao)息中間(jian)件的選(xuan)型(xing)(xing)，具體(ti)要結合用(yong)于哪一種業務場景，底座的選(xuan)型(xing)(xing)，考慮的因素(su)更(geng)多(duo)，比(bi)如：功能(neng)(neng)、性(xing)(xing)能(neng)(neng)、可靠性(xing)(xing)、擴(kuo)展性(xing)(xing)、社區生(sheng)態(tai)、開發語(yu)言。

4.1 架構

這(zhe)個是一個比較(jiao)大(da)的概念，對于消息中(zhong)間件來說，我們比較(jiao)關(guan)心(xin)2點(dian)，一是：服(fu)務 第二(er)是：存儲架構，架構首先就已經決定了性(xing)能、可靠性(xing)、可用(yong)性(xing)、擴展性(xing)等特(te)點(dian)。

4.2 消息服務能力

對于消息(xi)中間(jian)件(jian)選型，功能(neng)是(shi)優先要(yao)考(kao)慮(lv)的因(yin)素(su)，如果功能(neng)方面不滿足生產要(yao)求(qiu)，其他的也(ye)無(wu)從(cong)考(kao)慮(lv)。

• 優先級消息

對于消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)可以設置優先(xian)級(ji)，優先(xian)級(ji)高的消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)擁有(you)優先(xian)被(bei)(bei)消(xiao)(xiao)(xiao)(xiao)費(fei)的特權(quan)，這種(zhong)在是消(xiao)(xiao)(xiao)(xiao)費(fei)速(su)度(du)小于生產速(su)度(du)，產生消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)堆(dui)積的時候才會有(you)效。如果消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)速(su)度(du)大于生產速(su)度(du)，即生產的消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)馬上被(bei)(bei)消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)，優先(xian)級(ji)消(xiao)(xiao)(xiao)(xiao)息(xi)(xi)也就沒(mei)有(you)實際意(yi)義了。

• 延遲消息

某(mou)些場(chang)景中，希望(wang)投(tou)遞的消(xiao)息(xi)(xi)，不要立即被消(xiao)息(xi)(xi)，而是(shi)延(yan)遲一(yi)段(duan)時間。比(bi)如購買(mai)火車(che)票(piao)，選擇對應的車(che)次(ci)后，鎖(suo)定(ding)10分鐘(zhong)，如果(guo)該(gai)時段(duan)內沒有付款，將會取消(xiao)本次(ci)購買(mai)，釋放(fang)車(che)票(piao)，該(gai)場(chang)景就可(ke)以使用延(yan)遲消(xiao)息(xi)(xi)實現。從性能上考(kao)慮，一(yi)般采用固(gu)定(ding)的定(ding)時延(yan)遲，比(bi)如5s，10s,1m等(deng)等(deng)，這(zhe)樣可(ke)以將相同(tong)延(yan)遲時間的消(xiao)息(xi)(xi)放(fang)在一(yi)個(ge)延(yan)遲隊列中，批量處理和發送。

• 事務消息

在可靠性要求比較高的場景，預先發送或(huo)者(zhe)消費消息，再本(ben)地(di)邏輯處理，根據(ju)處理結果(guo)決定提交或(huo)者(zhe)回滾消息。一般采用(yong)二階段提交模式，當Broker沒有接受到commit或(huo)者(zhe)rollback指令(ling)，會回查該消息，確保消息被處理。

• 順序消息

保證(zheng)消息的生(sheng)產(chan)和消費(fei)有序性，很常見的場景(jing)就(jiu)是數(shu)據(ju)抽取CDC(Change Data Chapture)，以Mysql為例，需要(yao)確保binlog的抽取和消費(fei)的順序性，否則(ze)會導致(zhi)數(shu)據(ju)的不一致(zhi)。

• 死信隊列

某(mou)些異(yi)常(chang)(chang)場景下，導致消(xiao)(xiao)(xiao)息(xi)投遞失敗(bai)，或者(zhe)消(xiao)(xiao)(xiao)費(fei)失敗(bai)，為了確(que)保消(xiao)(xiao)(xiao)息(xi)的(de)不(bu)丟失，并且不(bu)影響其他消(xiao)(xiao)(xiao)息(xi)的(de)正常(chang)(chang)消(xiao)(xiao)(xiao)費(fei)，一般將(jiang)該異(yi)常(chang)(chang)消(xiao)(xiao)(xiao)費(fei)放置到特(te)定(ding)的(de)隊(dui)(dui)列(lie)(lie)(lie)，這個隊(dui)(dui)列(lie)(lie)(lie)被稱(cheng)之為死信隊(dui)(dui)列(lie)(lie)(lie)，死信隊(dui)(dui)列(lie)(lie)(lie)具(ju)有普通隊(dui)(dui)列(lie)(lie)(lie)的(de)所有特(te)性，也可(ke)以被消(xiao)(xiao)(xiao)費(fei)。通過監控(kong)死信隊(dui)(dui)列(lie)(lie)(lie)，可(ke)以查看(kan)異(yi)常(chang)(chang)消(xiao)(xiao)(xiao)息(xi)的(de)狀態。

• 重試隊列

對(dui)于某(mou)些(xie)明確(que)暫時無(wu)法處(chu)(chu)理，或者(zhe)應用業務層面處(chu)(chu)理失敗的(de)消息(xi)(xi)(xi)，希望過一段時間(jian)重試處(chu)(chu)理，這種(zhong)場景就需要(yao)使(shi)用到(dao)重試隊(dui)列(lie)(lie)，通(tong)常(chang)重試隊(dui)列(lie)(lie)可以(yi)指(zhi)(zhi)定(ding)重試次(ci)數，以(yi)免不(bu)斷循環處(chu)(chu)理一些(xie)永遠(yuan)都無(wu)法處(chu)(chu)理成功的(de)消息(xi)(xi)(xi)，重試隊(dui)列(lie)(lie)通(tong)常(chang)也需要(yao)配合死信(xin)(xin)隊(dui)列(lie)(lie)一起使(shi)用，重試策(ce)略中，指(zhi)(zhi)定(ding)消費多少(shao)次(ci)仍無(wu)法處(chu)(chu)理的(de)消息(xi)(xi)(xi)，轉(zhuan)移到(dao)死信(xin)(xin)隊(dui)列(lie)(lie)，監控死信(xin)(xin)隊(dui)列(lie)(lie)，以(yi)便(bian)業務補嘗(chang)處(chu)(chu)理或者(zhe)人工介入處(chu)(chu)理。

• 消息TTL

消息time to live，指(zhi)消息發送后，間隔(ge)多長(chang)時(shi)(shi)間允許被清理，對于一些對消息有時(shi)(shi)效性的使用場景。

• 批量發送

發送時，支持量發送，以提高(gao)性能

• 消息壓縮

支(zhi)持消(xiao)息壓縮，減少帶寬的占(zhan)用，以提(ti)高(gao)性能

• 失敗重試

支持失敗重試策略，減少失敗后，應用(yong)介入處理的工(gong)作(zuo)量

• 消息去重

大部份主流消(xiao)(xiao)(xiao)息(xi)中間件(jian)都做(zuo)不到(dao)僅(jin)(jin)(jin)僅(jin)(jin)(jin)一(yi)次(ci)的(de)(de)語(yu)義(yi)，這個和分布式CAP的(de)(de)制(zhi)(zhi)約有(you)關(guan)，如果實現(xian)僅(jin)(jin)(jin)僅(jin)(jin)(jin)一(yi)次(ci)的(de)(de)語(yu)義(yi)，需要使(shi)用事務消(xiao)(xiao)(xiao)息(xi)，引入更為復(fu)制(zhi)(zhi)的(de)(de)機制(zhi)(zhi)來處(chu)(chu)理(li)，消(xiao)(xiao)(xiao)息(xi)重(zhong)復(fu)，在生產階段，一(yi)般是(shi)由于，失敗(bai)重(zhong)試造(zao)成的(de)(de)，消(xiao)(xiao)(xiao)息(xi)去重(zhong)能保證在發送階段消(xiao)(xiao)(xiao)息(xi)的(de)(de)僅(jin)(jin)(jin)僅(jin)(jin)(jin)一(yi)次(ci)的(de)(de)語(yu)義(yi)（要實現(xian)消(xiao)(xiao)(xiao)息(xi)端(duan)到(dao)端(duan)僅(jin)(jin)(jin)僅(jin)(jin)(jin)一(yi)次(ci)的(de)(de)語(yu)義(yi)，消(xiao)(xiao)(xiao)費(fei)端(duan)也(ye)需用一(yi)定(ding)的(de)(de)策(ce)略來處(chu)(chu)理(li)）

• 持久化、非持久化

持(chi)久(jiu)化(hua)是(shi)指對確認(ren)發送成功的(de)消息(xi)(xi)(xi)，實現可靠的(de)持(chi)久(jiu)化(hua)；非久(jiu)持(chi)久(jiu)剛好相(xiang)反，不需對消息(xi)(xi)(xi)做持(chi)久(jiu)化(hua)，通常用(yong)在一(yi)些可接受消息(xi)(xi)(xi)丟失的(de)場景，比如(ru):日志、監控指標(biao)的(de)采集，優點就是(shi)性能更優，而且不需要占用(yong)存儲，有一(yi)定的(de)應用(yong)場景

• 消費模式

消(xiao)(xiao)(xiao)(xiao)費(fei)模(mo)(mo)式(shi)(shi)(shi)分為"推"和"拉(la)"兩種模(mo)(mo)式(shi)(shi)(shi)，"推"模(mo)(mo)式(shi)(shi)(shi)是Broker主動(dong)將消(xiao)(xiao)(xiao)(xiao)息(xi)推送(song)到消(xiao)(xiao)(xiao)(xiao)費(fei)端(duan)，這種模(mo)(mo)式(shi)(shi)(shi)，實時性較(jiao)好，不過要有(you)措(cuo)施確保(bao)消(xiao)(xiao)(xiao)(xiao)息(xi)端(duan)的處理(li)能力(li)，不要被壓垮(kua)；"拉(la)"模(mo)(mo)式(shi)(shi)(shi)是消(xiao)(xiao)(xiao)(xiao)費(fei)端(duan)主動(dong)從Broker獲(huo)取消(xiao)(xiao)(xiao)(xiao)息(xi)，消(xiao)(xiao)(xiao)(xiao)費(fei)端(duan)可以自身(shen)的處理(li)能力(li)確定(ding)獲(huo)取消(xiao)(xiao)(xiao)(xiao)息(xi)的速度，但實時性較(jiao)差。

• 消息簽收

消(xiao)(xiao)息(xi)(xi)簽(qian)(qian)收(shou)是指消(xiao)(xiao)息(xi)(xi)消(xiao)(xiao)費(fei)完成后，對(dui)已消(xiao)(xiao)費(fei)消(xiao)(xiao)息(xi)(xi)的ack確認信(xin)息(xi)(xi)，消(xiao)(xiao)息(xi)(xi)系統(tong)，一(yi)般(ban)有兩(liang)種(zhong)常(chang)見(jian)的簽(qian)(qian)收(shou)策略，單條(tiao)簽(qian)(qian)收(shou)、累積(ji)簽(qian)(qian)收(shou)，比(bi)如(ru)：Kafka、RocketMQ僅支持累積(ji)簽(qian)(qian)收(shou)，服務端，單個(ge)(ge)消(xiao)(xiao)費(fei)組、單個(ge)(ge)分區(qu)，只(zhi)保留一(yi)個(ge)(ge)簽(qian)(qian)收(shou)進(jin)行，累積(ji)簽(qian)(qian)收(shou)的的優點(dian)是：實現(xian)邏輯(ji)簡單、性能好，但一(yi)旦消(xiao)(xiao)費(fei)實例(li)重啟、或者隊列重平衡(heng)，可能導致(zhi)大量的重復消(xiao)(xiao)息(xi)(xi)。

• 訂閱模式

訂(ding)閱模(mo)式(shi)(shi)包括(kuo)點對點模(mo)式(shi)(shi)和發布(bu)訂(ding)閱模(mo)式(shi)(shi)，點對點模(mo)式(shi)(shi)，生產的消息(xi)僅(jin)(jin)能被(bei)一(yi)個(ge)(ge)(ge)消費(fei)者(zhe)消費(fei)；發布(bu)訂(ding)閱模(mo)式(shi)(shi)，生產的消息(xi)被(bei)所有訂(ding)閱的消費(fei)端消費(fei)。實際生產過程(cheng)中，很多時候是(shi)這兩種(zhong)模(mo)式(shi)(shi)的組合，比如在電商業務中，用戶(hu)下單成功的消息(xi)需要被(bei)物流，供應(ying)商等(deng)多個(ge)(ge)(ge)系(xi)統(tong)同時消費(fei)，這種(zhong)是(shi)發布(bu)訂(ding)閱模(mo)式(shi)(shi)；每個(ge)(ge)(ge)系(xi)統(tong)的消費(fei)者(zhe)為集(ji)群模(mo)式(shi)(shi)，僅(jin)(jin)能被(bei)其中某個(ge)(ge)(ge)實例(li)消費(fei)，此時又(you)是(shi)點對點模(mo)式(shi)(shi)。

• 消息堆積

削峰(feng)是MQ主要場景(jing)之一(yi)，當(dang)消息(xi)洪峰(feng)到來，消息(xi)無法來得及處理，此(ci)時就需要依賴(lai)中間件的(de)消息(xi)堆積(ji)能力，實(shi)現(xian)延遲消費。一(yi)般通過大容量磁盤實(shi)現(xian)消息(xi)的(de)持久化存儲(chu)。

• 消息回溯

在(zai)有些(xie)場景下，消(xiao)息(xi)(xi)被(bei)正確(que)的(de)消(xiao)費(fei)了，但是由(you)于某些(xie)異(yi)常(chang)情況，導(dao)致下游的(de)消(xiao)息(xi)(xi)丟失，比如數據庫(ku)磁(ci)盤(pan)損(sun)壞(huai)等，此時(shi)需要指(zhi)定(ding)消(xiao)息(xi)(xi)的(de)位置(zhi)，進行回溯和重新消(xiao)費(fei)。消(xiao)息(xi)(xi)回溯功能對于保證消(xiao)息(xi)(xi)“不(bu)丟失”非常(chang)重要。

• 消息過濾

按一定的(de)(de)過(guo)濾規(gui)則為(wei)下游消(xiao)費者提供消(xiao)息，過(guo)濾規(gui)則包括值(zhi)匹配，范圍，以及SQL語句，當然(ran)，消(xiao)息過(guo)濾會損耗一定的(de)(de)性能。在(zai)跨機(ji)房轉(zhuan)發的(de)(de)場(chang)景(jing)中，可以通過(guo)消(xiao)息過(guo)濾將特定的(de)(de)部分(fen)消(xiao)息轉(zhuan)發到其他機(ji)房。

• 消息的查詢和追蹤

消息從哪(na)里來，最(zui)終又(you)到哪(na)里去(qu)了，消息的鏈(lian)路(lu)追蹤對(dui)于問題的定位和排(pai)查非常重要。

• 消息清除

對于已消費過，或者超(chao)期的(de)消息實施清除(chu)，以確保足夠的(de)空間接受新(xin)的(de)消息。

• 資源隔離

在(zai)共享(xiang)相(xiang)同(tong)的(de)(de)系統或程序(xu)組件的(de)(de)場(chang)景(jing)下，實(shi)現租戶之(zhi)間數據的(de)(de)隔離。一套集群就可以服務多個(ge)租戶，多租戶帶來了(le)成本的(de)(de)降低和運營的(de)(de)簡便；Pulsar的(de)(de)namespace、或者(zhe)RabbitMQ的(de)(de)vhost同(tong)樣屬(shu)于支持資(zi)源隔離。

• 資源配額

不同接(jie)入用戶或者客戶端或者，不同的資源(yuan)對象可以使(shi)用的資源(yuan)配額，配額一般有：連接(jie)數、流量、TPS、存儲容量等

• 安全性

消息中間件也可以(yi)看(kan)做是(shi)存儲模塊，如果存在(zai)敏(min)感數據或者保密(mi)性(xing)要求高，那(nei)么安(an)全性(xing)是(shi)必選(xuan)項(xiang)。MQ的(de)安(an)全性(xing)需(xu)要包括身份(fen)認證(zheng)和(he)權限控制，身份(fen)認證(zheng)是(shi)指(zhi)客戶端(duan)與(yu)Broker，Broker與(yu)Broker之(zhi)間的(de)連接(jie)認證(zheng)；權限控制是(shi)指(zhi)對客戶端(duan)的(de)讀(du)寫操作進行權限控制，另外部分消息中間件支持消息端(duan)到端(duan)的(de)加密(mi)，當然在(zai)應用端(duan)自行實例加密(mi)也可以(yi)。

• 配置

支持(chi)資(zi)源級(ji)別的配置(zhi)(zhi)，比較Kafka的支持(chi)Broker級(ji)別、主題級(ji)別的配置(zhi)(zhi)，但像RocketMQ公支持(chi)Broker級(ji)別的配置(zhi)(zhi)，對于多業務(wu)應用共享(xiang)的集群(qun)無法做到根據不同的業務(wu)需求靈(ling)活配置(zhi)(zhi)。

4.3 性能

消(xiao)息中(zhong)(zhong)間(jian)件(jian)的(de)(de)性能是(shi)選(xuan)型的(de)(de)重(zhong)要考慮條件(jian)，消(xiao)息中(zhong)(zhong)間(jian)件(jian)的(de)(de)架構、消(xiao)息存儲(chu)機器已經決定了消(xiao)息中(zhong)(zhong)間(jian)件(jian)的(de)(de)性能范圍，后(hou)續(xu)進行(xing)二次(ci)開(kai)發，如果在不變列架構、存儲(chu)機制的(de)(de)前提(ti)下，性能一般(ban)很難(nan)會有大(da)的(de)(de)突(tu)破，所以為了減少(shao)二次(ci)開(kai)發的(de)(de)難(nan)度(du)及工作量(liang)，性能是(shi)選(xuan)型最需關注的(de)(de)指(zhi)標。

4.4 可靠性

可(ke)靠(kao)性(xing)(xing)也是(shi)消(xiao)息中間件(jian)(jian)重要的(de)指標，需要確(que)保 消(xiao)息的(de)不丟(diu)失(shi)(shi)，對于(yu)某些特(te)定的(de)場景，比(bi)如金融(rong)，消(xiao)息的(de)可(ke)靠(kao)性(xing)(xing)是(shi)要嚴格(ge)得到保證(zheng)。但是(shi)沒有(you)任(ren)何一款中間件(jian)(jian)能(neng)100%確(que)保消(xiao)息的(de)不丟(diu)失(shi)(shi)，且可(ke)靠(kao)性(xing)(xing)要求越高，必然(ran)能(neng)損(sun)失(shi)(shi)部(bu)分性(xing)(xing)能(neng)，比(bi)如同(tong)步(bu)發送，事務消(xiao)息，同(tong)步(bu)落(luo)盤等，都(dou)是(shi)以損(sun)耗性(xing)(xing)能(neng)為(wei)代(dai)價，魚與熊掌不可(ke)兼得。

廣義上的可(ke)靠性，也(ye)包含可(ke)用性，故障(zhang)發送時，能(neng)快速(su)轉(zhuan)移和恢復(fu)，對業務的影響(xiang)降(jiang)到最(zui)低。中(zhong)間(jian)件采用主從，分(fen)布式集群等架構模式，滿足對可(ke)用性的要求(qiu)。

4.5 可用性、擴展性

可(ke)用性，是指(zhi)在在一(yi)個或者多個服(fu)務(wu)(wu)節點無法正常(chang)提(ti)供(gong)服(fu)務(wu)(wu)的情況下，整個集群仍能(neng)提(ti)供(gong)全部(bu)或者受限的服(fu)務(wu)(wu)，保證重要功能(neng)仍能(neng)正常(chang)使用。

擴(kuo)(kuo)展性，有兩個方面，一是(shi)指集群的擴(kuo)(kuo)容，對應用來(lai)說能(neng)做(zuo)受到無(wu)(wu)感知擴(kuo)(kuo)容，無(wu)(wu)論計算或者(zhe)存儲(chu)能(neng)力(li)，都(dou)可以(yi)做(zuo)到在線、透明(ming)擴(kuo)(kuo)容，二是(shi)指消息中間件本身可以(yi)進(jin)行擴(kuo)(kuo)展，通過(guo)二次開發達到擴(kuo)(kuo)展消息服務能(neng)力(li)的目(mu)的。

4.6 社區生態度

這條(tiao)也是選(xuan)擇中(zhong)間的(de)現實考慮因素(su)之一(yi)，特別對(dui)于中(zhong)小企業(ye)，這個(ge)可能成(cheng)為最(zui)優(you)先考慮因素(su)，如果選(xuan)擇的(de)中(zhong)間件與(yu)團隊(dui)的(de)技能不匹配，或者中(zhong)間件的(de)社區活躍讀不高(gao)，就(jiu)意(yi)味后續需要投入更多成(cheng)本進行學習和踩(cai)坑。

當然選型過(guo)程(cheng)中，還有其他很多考慮因素，比如運維工(gong)具，項(xiang)目(mu)的繼承性等(deng)等(deng)。總之，沒有一(yi)個中間(jian)件能包治百(bai)病，只能對癥下藥(yao)，綜(zong)合(he)各(ge)種因素，最大程(cheng)度選擇適(shi)合(he)自己的。

4.7 SDK、協議

主要有兩方(fang)面：1.SDK易用性 2.支持(chi)更多的(de)的(de)語(yu)(yu)言(yan)的(de)SDK，易用性對應用使用更友好，不用過多的(de)處理(li)一些細節(jie)問題，比如(ru)：服務端有節(jie)點離(li)線、連(lian)接斷開(kai)等，當用易用性不單單這些，包(bao)括(kuo)方(fang)方(fang)面面。多語(yu)(yu)言(yan)SDK，方(fang)便使用不同語(yu)(yu)語(yu)(yu)言(yan)開(kai)發的(de)應用能輕松集成SDK，廣義來(lai)說(shuo)，SDK也(ye)包(bao)括(kuo)了對公共應用層協議(yi)的(de)支持(chi)，比如(ru)：HTTP、WebSocket等

4.8 運維管理

完善的運維管理機制，主要包括：

1. 命令行 基本主流的消息中間件都提供了命令行運維工具，方便專業運維人員對服務的運維工作
2. 運維控制臺 通常是對命令行或者管理API的封裝，對集群進行管理，運維控制臺，以更直觀的方觀進行運維管理操作，更加友好，比如RabbitMQ managerment
3. 管理API 管理API通常是方便運維管理功能，對于用戶開發非常重要
4. 規范的監控數據（比如Promethus規范）