一、什么是 MQ

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

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

二、MQ 的作用

1. 流量削峰

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

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

2. 應(yīng)用解耦

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

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

現(xiàn)在加上 MQ 后，訂單系統(tǒng)的工作完成后，接下來的事情就轉(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)不受影響，用戶感覺不出來有異常，依舊可以看到成功下單的提示。當(dāng)物流系統(tǒng)恢復(fù)正常以后，繼續(xù)處理訂單信息即可，從而提升了整個(gè)系統(tǒng)的可用性。

3. 異步處理

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

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

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

三、MQ 的缺點(diǎn)

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

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

對(duì)于一致性問題，在 testerhome 有看到過一位大佬分享的經(jīng)驗(yàn)：
首先，消費(fèi)者在消費(fèi)成功后通過同步請求或者另一條 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 同步查詢給消費(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)重的問題，如加劇 mq 消息堆積的情況）

四、常見 MQ 分類

1. ActiveMQ

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

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

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

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

2. Kafka

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

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

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

缺點(diǎn)

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

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

3. RocketMQ

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

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

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

缺點(diǎn)

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

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

4. RabbitMQ

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

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

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

缺點(diǎn)

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

RabbitMQ 性能好，時(shí)效性強(qiáng)，管理界面也很友好。如果數(shù)據(jù)量沒那么大，中心型業(yè)務(wù)可以優(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ù)包，來封裝業(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 測試需要的關(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á)到上限，無法推送后如何處理

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

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

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

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

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

最后本文參考文章

http://chabaoo.cn/article/249620.htm

http://chabaoo.cn/article/219482.htm

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

最新評(píng)論