一、什么是 MQ

MQ全稱(chēng)是 Message Queue，本質(zhì)上是個(gè)隊(duì)列，原則還是先進(jìn)先出，只不過(guò)隊(duì)列里存放的元素是一條條 Message 。

工作中常見(jiàn)被用于上下游傳遞消息，實(shí)現(xiàn)一種跨進(jìn)程的通信。這樣一來(lái)，要發(fā)送消息的上游服務(wù)只依賴(lài) MQ 即可，與下游服務(wù)解耦，我覺(jué)得可以理解成中介。

二、MQ 的作用

1. 流量削峰

舉個(gè)栗子，這里有一個(gè)訂單系統(tǒng)處理用戶(hù)下單的業(yè)務(wù)邏輯。這個(gè)系統(tǒng)的服務(wù)能力假設(shè)為 1S 處理1萬(wàn)次訂單，那么正常來(lái)說(shuō)，不超過(guò)1萬(wàn)次對(duì)它來(lái)說(shuō)都沒(méi)問(wèn)題。但是，如果到了用戶(hù)下單的高峰期，這時(shí)候的單量可能就要超過(guò)系統(tǒng)服務(wù)能力。

這時(shí)候可以加入 MQ，把1s內(nèi)下的訂單進(jìn)行排隊(duì)，分散在一段時(shí)間內(nèi)處理，雖然說(shuō)會(huì)導(dǎo)致有些用戶(hù)會(huì)在幾秒之后才能收到下單成功，但是比起不能下單還是要好很多了。

2. 應(yīng)用解耦

現(xiàn)在有個(gè)電商應(yīng)用，里面包含了好多個(gè)子系統(tǒng)：訂單系統(tǒng)、庫(kù)存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng)等。

先看下耦合在一起的情況，當(dāng)用戶(hù)創(chuàng)建訂單后，如果后面任何一個(gè)子系統(tǒng)出現(xiàn)了故障，都會(huì)造成用戶(hù)的下單操作異常。

現(xiàn)在加上 MQ 后，訂單系統(tǒng)的工作完成后，接下來(lái)的事情就轉(zhuǎn)交給MQ了。MQ 會(huì)分配消息給其他的3個(gè)系統(tǒng)，直到3個(gè)系統(tǒng)執(zhí)行完成。如果存在其中有不能完成的系統(tǒng)，隊(duì)列會(huì)監(jiān)督它繼續(xù)完成。比如物流系統(tǒng)壞了，但是訂單系統(tǒng)不受影響，用戶(hù)感覺(jué)不出來(lái)有異常，依舊可以看到成功下單的提示。當(dāng)物流系統(tǒng)恢復(fù)正常以后，繼續(xù)處理訂單信息即可，從而提升了整個(gè)系統(tǒng)的可用性。

3. 異步處理

在生產(chǎn)中，有些服務(wù)間的調(diào)用是異步的。A 調(diào)用 B，但是 B 需要花費(fèi)一段時(shí)間來(lái)處理。沒(méi)有 MQ 的時(shí)候通常這樣處理：

• A 輪詢(xún)的調(diào)用 B的查詢(xún)，看看結(jié)果是不是處理好了。
• A 提供一個(gè)callback 回調(diào)接口，B 執(zhí)行好了調(diào)用這個(gè)api接口通知 A。

加入 MQ 后，這時(shí) A 再調(diào)用 B 后，只需要監(jiān)聽(tīng) B 處理完成的消息即可。當(dāng) B 處理完成后，會(huì)發(fā)送一條消息給 MQ，然后 MQ 會(huì)把消息轉(zhuǎn)發(fā)給 A。所以，現(xiàn)在 A 既不用輪詢(xún) B，也不用提供回調(diào)api

三、MQ 的缺點(diǎn)

MQ 這么好用，難道就沒(méi)有缺點(diǎn)嗎？ 有。

• 首先，在系統(tǒng)里加入了一個(gè)中間件服務(wù)，無(wú)疑是會(huì)增加了系統(tǒng)復(fù)雜度。
• 如果 MQ 宕機(jī)了，不能用了，那么后面的流程也沒(méi)法處理了。
• 存在一致性問(wèn)題。比如訂單系統(tǒng)創(chuàng)建好了訂單，發(fā)給下游的消息沒(méi)發(fā)出去，那么就產(chǎn)生了臟數(shù)據(jù)。再比如，先發(fā)送了訂單的消息，再去創(chuàng)建訂單，如果創(chuàng)建失敗了，消息卻發(fā)送成功了，此時(shí)下游以為已經(jīng)創(chuàng)建好了訂單。
• 其他問(wèn)題，比如消息丟失，重復(fù)發(fā)送相同消息，消息被其他系統(tǒng)消費(fèi)，消息大量積壓等等，都需要我們有對(duì)應(yīng)方案解決。

對(duì)于一致性問(wèn)題，在 testerhome 有看到過(guò)一位大佬分享的經(jīng)驗(yàn)：
首先，消費(fèi)者在消費(fèi)成功后通過(guò)同步請(qǐng)求或者另一條 mq 隊(duì)列，反饋給生產(chǎn)者，生產(chǎn)者更新自己內(nèi)部這條消息的狀態(tài)為已處理。

同時(shí)生產(chǎn)者內(nèi)置一個(gè)定時(shí)任務(wù)，查看內(nèi)部所有待處理消息是否超時(shí)，如果超時(shí)，進(jìn)行自動(dòng)補(bǔ)償。補(bǔ)償大概步驟是：

• 發(fā)起 http 同步查詢(xún)給消費(fèi)者，確認(rèn)消費(fèi)者是否有消費(fèi)
• 若消費(fèi)者反饋已消費(fèi)，直接更新生產(chǎn)者自身內(nèi)部消息狀態(tài)
• 若消費(fèi)者反饋未收到，則進(jìn)行預(yù)警，人工介入處理（一般不會(huì)直接重發(fā)，因?yàn)橹匕l(fā)有可能引發(fā)更嚴(yán)重的問(wèn)題，如加劇 mq 消息堆積的情況）

四、常見(jiàn) MQ 分類(lèi)

1. ActiveMQ

Apache下的一個(gè)子項(xiàng)目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，少量代碼就可以高效地實(shí)現(xiàn)高級(jí)應(yīng)用場(chǎng)景。

優(yōu)點(diǎn)：

• 單機(jī)吞吐量： 萬(wàn)級(jí)。
• 時(shí)效性： ms級(jí)。
• 可用性：高。
• 消息可靠性：較低概率出現(xiàn)丟失數(shù)據(jù)。

缺點(diǎn)
官方社區(qū)現(xiàn)在對(duì)于 ActiveMQ 5.x的版本維護(hù)越來(lái)越少，高吞吐量場(chǎng)景較少使用。

2. Kafka

Apache下的一個(gè)子項(xiàng)目，使用scala實(shí)現(xiàn)的一個(gè)高性能分布式Publish/Subscribe消息隊(duì)列系統(tǒng)。尤其在大數(shù)據(jù)上是個(gè)殺手锏，吞吐量在百萬(wàn)級(jí)，在數(shù)據(jù)采集、傳輸、存儲(chǔ)的過(guò)程中發(fā)揮舉足輕重的作用。

優(yōu)點(diǎn)

• 單機(jī)吞吐量： 百萬(wàn)級(jí)。
• 時(shí)效性： ms級(jí)。
• 可用性：非常高。
• 消息可靠性：可配置 0 丟失。
• 分布式：一個(gè)數(shù)據(jù)有多個(gè)副本，少數(shù)機(jī)器宕機(jī)也不會(huì)丟失數(shù)據(jù)。

缺點(diǎn)

• 單機(jī)超過(guò)64個(gè)隊(duì)列/分區(qū)，CPU會(huì)明顯變高，隊(duì)列越多越高，發(fā)送消息響應(yīng)時(shí)間變長(zhǎng)。
• 消費(fèi)失敗不支持重試。

Kafka主要特點(diǎn)是基于PULL的模式來(lái)處理消息消費(fèi)，追求高吞吐量，一開(kāi)始的目的就是用于日志收集和傳輸，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。

3. RocketMQ

阿里系下開(kāi)源的一款分布式、隊(duì)列模型的消息中間件，是阿里參照kafka設(shè)計(jì)思想使用java實(shí)現(xiàn)的一套MQ，并做了自己的改進(jìn)。被阿里廣泛的應(yīng)用在訂單、交易、充值、流計(jì)算、消息推送、日志流處理等場(chǎng)景。

優(yōu)點(diǎn)

• 單機(jī)吞吐量： 十萬(wàn)級(jí)。
• 時(shí)效性： ms級(jí)。
• 可用性：非常高。
• 消息可靠性：可配置 0 丟失。
• 分布式：支持。
• 擴(kuò)展性好，支持10億級(jí)別的消息堆積。
• 源碼是java，有利于定制。

缺點(diǎn)

支持的語(yǔ)言不多，主要是java，C++還不成熟。社區(qū)活躍也一般，沒(méi)有在 MQ 核心中實(shí)現(xiàn) JMS 等接口，有些系統(tǒng)需要遷移則要修改大量代碼。

RocketMQ 天生為了金融互聯(lián)網(wǎng)而生，對(duì)于可靠性要求很高的場(chǎng)景，比如電商里的扣款，它更值得信賴(lài)。

4. RabbitMQ

使用Erlang編寫(xiě)的一個(gè)開(kāi)源的消息隊(duì)列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級(jí)，更適合于企業(yè)級(jí)的開(kāi)發(fā)。

優(yōu)點(diǎn)

• 單機(jī)吞吐量： 萬(wàn)級(jí)。
• 時(shí)效性：μs級(jí)。
• 可用性：高。
• 消息可靠性：基本不丟失。
• 支持多語(yǔ)言。
• 社區(qū)活躍度高，更新頻率高

缺點(diǎn)

商業(yè)版需要付費(fèi)，學(xué)習(xí)成本較高。

RabbitMQ 性能好，時(shí)效性強(qiáng)，管理界面也很友好。如果數(shù)據(jù)量沒(méi)那么大，中心型業(yè)務(wù)可以?xún)?yōu)先選擇功能完備的 RabbitMQ。

五、MQ 的組成

1. 角色

• Broker：消息服務(wù)器，提供消息核心服務(wù)
• Producer：消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負(fù)責(zé)生產(chǎn)消息傳輸給broker。
• Consumer：消息消費(fèi)者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理。
• Topic：主題，發(fā)布訂閱模式下的消息統(tǒng)一匯集地，不同生產(chǎn)者向topic發(fā)送消息，由MQ服務(wù)器分發(fā)到不同的訂閱者，實(shí)現(xiàn)消息的廣播。
• Queue：隊(duì)列，點(diǎn)對(duì)點(diǎn)模式下，特定生產(chǎn)者向特定queue發(fā)送消息，消費(fèi)者訂閱特定的queue完成指定消息的接收。
• Message：消息體，根據(jù)不同通信協(xié)議定義的固定格式進(jìn)行編碼的數(shù)據(jù)包，來(lái)封裝業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)消息的傳輸。

2. MQ 消息模式

1)點(diǎn)對(duì)點(diǎn)模式

使用 queue 作為通信載體，消息生產(chǎn)者生產(chǎn)消息發(fā)送到 queue 中，然后消息消費(fèi)者從 queue 中取出并且消費(fèi)消息。

• 消息被消費(fèi)以后，queue中不再存儲(chǔ)，所以消息消費(fèi)者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。
• Queue支持存在多個(gè)消費(fèi)者，但是對(duì)一個(gè)消息而言，只會(huì)有一個(gè)消費(fèi)者可以消費(fèi)。

2)發(fā)布訂閱模式

使用topic作為通信載體，1個(gè)生產(chǎn)者可以對(duì)應(yīng)多個(gè)消費(fèi)者。消息生產(chǎn)者(發(fā)布)將消息發(fā)布到topic中，同時(shí)有多個(gè)消息消費(fèi)者(訂閱)消費(fèi)該消息。和點(diǎn)對(duì)點(diǎn)方式不同，發(fā)布到topic的消息會(huì)被所有訂閱者消費(fèi)。

就像你發(fā)了個(gè)朋友圈，你的朋友們都可以看到。

六、MQ 測(cè)試需要的關(guān)注點(diǎn)

1. 對(duì)于生產(chǎn)者

• 生成的數(shù)據(jù)格式是否跟定義的一致
• 數(shù)據(jù)是否有成功推送到隊(duì)列里
• 數(shù)據(jù)是否有成功推動(dòng)到對(duì)應(yīng)的 topic
• 推送失敗時(shí)如何處理
• 重復(fù)推送同一條數(shù)據(jù)，如何處理
• 不同順序推送消息，注意隊(duì)列優(yōu)先級(jí)
• 推消息耗時(shí)，隊(duì)列容量達(dá)到上限，無(wú)法推送后如何處理

2. 對(duì)于消費(fèi)者

• 消費(fèi)的消息是否來(lái)自訂閱的 topic
• 消息被消費(fèi)了，是否有清除
• 生產(chǎn)者推送過(guò)快，消費(fèi)速度過(guò)慢（堵塞），會(huì)如何
• 無(wú)法消費(fèi)沒(méi)訂閱的 topic 消息
• 生產(chǎn)者推送消息后，消費(fèi)者接受到的消息內(nèi)容跟生產(chǎn)者推的一致
• 如何處理重復(fù)消息，比如冪等
• 處理超時(shí)
• 消息處理失敗
• 消費(fèi)消息的優(yōu)先級(jí)是否跟推的一致
• 消費(fèi)消息耗時(shí)
• 消費(fèi)者宕機(jī)，消息堆積，無(wú)人處理，會(huì)如何處理
• 是否能正常消費(fèi)消息

3. 對(duì)于隊(duì)列

• 宕機(jī)恢復(fù)后，消息是否丟失
• 宕機(jī)預(yù)案，多久能恢復(fù)，如果無(wú)法恢復(fù)的預(yù)案
• 不同的消息格式，是否能正常識(shí)別及轉(zhuǎn)發(fā)

具體關(guān)注點(diǎn)，其實(shí)還要看具體業(yè)務(wù)來(lái)，這些都可以做些了解，如果有涉及到與MQ交互的，可以從多方面去考慮，增加測(cè)試覆蓋。

最后本文參考文章

http://www.dhdzp.com/article/249620.htm

http://www.dhdzp.com/article/219482.htm

以上就是MQ的分類(lèi)組成優(yōu)缺點(diǎn)測(cè)試點(diǎn)入門(mén)教程的詳細(xì)內(nèi)容，更多關(guān)于MQ分類(lèi)組成測(cè)試點(diǎn)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！