一、什么是 MQ

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

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

二、MQ 的作用

1. 流量削峰

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

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

2. 應用解耦

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

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

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

3. 異步處理

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

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

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

三、MQ 的缺點

MQ 這么好用，難道就沒有缺點嗎？ 有。

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

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

同時生產(chǎn)者內(nèi)置一個定時任務，查看內(nèi)部所有待處理消息是否超時，如果超時，進行自動補償。補償大概步驟是：

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

四、常見 MQ 分類

1. ActiveMQ

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

優(yōu)點：

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

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

2. Kafka

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

優(yōu)點

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

缺點

• 單機超過64個隊列/分區(qū)，CPU會明顯變高，隊列越多越高，發(fā)送消息響應時間變長。
• 消費失敗不支持重試。

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

3. RocketMQ

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

優(yōu)點

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

缺點

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

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

4. RabbitMQ

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

優(yōu)點

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

缺點

商業(yè)版需要付費，學習成本較高。

RabbitMQ 性能好，時效性強，管理界面也很友好。如果數(shù)據(jù)量沒那么大，中心型業(yè)務可以優(yōu)先選擇功能完備的 RabbitMQ。

五、MQ 的組成

1. 角色

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

2. MQ 消息模式

1)點對點模式

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

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

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

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

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

六、MQ 測試需要的關注點

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

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

2. 對于消費者

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

3. 對于隊列

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

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

最后本文參考文章

http://www.dbjr.com.cn/article/249620.htm

http://www.dbjr.com.cn/article/219482.htm

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

最新評論