前言

上一篇小結了一下關于redis的異常測試，今天再來盤一盤 MQ 相關的。

MQ 跟 redis 一樣，也是現(xiàn)在系統(tǒng)服務中不可或缺的重要中間件，通常用來流量削峰、應用解耦、異步處理等。

之前有過一篇整理【MQ 快速入門】介紹、分類、組成、優(yōu)缺點、測試點，有興趣也可以跳過去看看。

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

這里再簡述一些知識點。

一、RocketMQ 消息模式

RocketMQ中，也存在兩種消息模式，分別為集群消費模式和廣播消費模式。

集群消費模式

RocketMQ默認的消息模式就是集群模式，當存在多個消費者時，消息通過一定負載均衡策略，將消息分發(fā)到多個consumer中。

比如現(xiàn)在有3個消費者，那么一條消息投遞過來，只會被consumer 1、consumer 2、consumer 3中的一個消費。

在RockeMQ中，通過ConsumeGroup的機制，實現(xiàn)了天然的消息負載均衡，可以非常方便的通過加機器來實現(xiàn)水平擴展。

廣播消費模式

這種模式下，會把消息分發(fā)給每一個消費者。一條消息投遞過來，會被 consumer 1、consumer 2、consumer 3都消費一次，就像發(fā)了條朋友圈，你的朋友都可以看見。

目前我們用的比較多的是集群模式，在集群模式也可以模擬廣播消費。

二、push 和 pull 優(yōu)缺點

對于任何一款消息中間件而言，消費者客戶端一般有兩種方式從消息中間件獲取消息并消費。

Pull方式

由消費者客戶端主動向消息中間件（MQ消息服務器代理）拉取消息。

適用場景：對于生產者生產消息數(shù)據(jù)比較大時，而消費端處理比較復雜，消費能力相對較低。

優(yōu)點：消費者可以依據(jù)自己的消費能力進行消費，生產者不需要維護和消費者之間的會話。

缺點：拉取消息的間隔不太好設置。間隔太短，對服務器請求壓力過大。間隔時間過長，那么必然會造成一部分數(shù)據(jù)的延遲，實時性相對較低。

優(yōu)化方案：

長輪詢的消費方式，需要Server和Client的配合才能夠實現(xiàn)。

即Client發(fā)送消息請求，Server端接受請求，如果發(fā)現(xiàn)Server隊列里沒有新消息，Server端不立即返回，而是持有這個請求一段時間（通過設置超時時間來實現(xiàn)），在這段時間內輪詢Server隊列內是否有新的消息，如果有新消息，就利用現(xiàn)有的連接返回消息給消費者；如果這段時間內沒有新消息進入隊列，則返回空。

長輪詢的弊端：在持有消費者請求的這段時間，占用了系統(tǒng)資源，因此長輪詢適合客戶端連接數(shù)可控的業(yè)務場景中。

Push方式

由消息服務端主動地將消息推送給消費者，盡可能實時地將消息發(fā)送給消費者進行消費。

適用場景：對于數(shù)據(jù)實時性要求高的場景。

優(yōu)點：生產者主動推送給消費者，及時性很高。

缺點：當消費者消費能力遠低于生產者生產能力，那么一旦生產者推送大量消息到消費者時，就會導致消費者消息堆積，處理緩慢，甚至服務崩潰。

另外，生產者需要維護和每個消費者之間的會話。

優(yōu)化方案：不采用 http 長連接的方法保持會話，采用 socket 監(jiān)聽。

三、刷盤策略

RocketMQ的存儲讀寫是基于JDK NIO的內存映射機制的，消息存儲時首先將消息追加到內存中，再根據(jù)不同的刷盤策略在不同的時間進行刷盤。

同步刷盤

同步刷盤是指數(shù)據(jù)到達內存之后，必須刷到commitlog日志之后才算成功，然后返回producer數(shù)據(jù)已經發(fā)送成功。

異步刷盤

指數(shù)據(jù)到達內存之后,返回producer說數(shù)據(jù)已經發(fā)送成功，然后再寫入commitlog日志。

什么是commitlog？

commitlog 就是來存儲所有的元信息，包含消息體，類似于Mysql、Oracle 的 redolog。所以只要有 CommitLog 在，Consume Queue即使數(shù)據(jù)丟失，仍然可以恢復出來。

而 consumequeue，就是用來記錄數(shù)據(jù)的位置，以便 Consumer 快速通過 consumequeue 找到 commitlog 中的數(shù)據(jù)。

四、MQ 異常測試

MQ消息體

MQ消息體中某些必填參數(shù)為 NULL，或者全部必填都為NULL，字段類型、長度是否不符合約定等。

消息重復發(fā)送

消息重復發(fā)送，只消費一條，一般根據(jù)消息內容中唯一標識來去重。

消息到達順序不一致

消息到達順序不一致，導致業(yè)務異常。

比如：訂單下單后再取消，如果先收到取消的消息，再收到下單消息，就會有問題。

消息發(fā)送失敗重試

Producer端重試

比如網(wǎng)絡抖動導致生產者發(fā)送消息到MQ失敗，可以手動設置發(fā)送失敗重試的次數(shù)。

Consumer端重試

默認16次，重試時間間隔會越來越長，如果失敗的多，容易堆積。這里的重試次數(shù)可自定義設置。

值得注意的是，只有消息推送失敗才需要重推，不要把其他失敗的情況也進行重試。

接線上生產者

接線上已有的生產者，需要注意，必須設置消費開始時間，不然上線時會大批量消息過來會造成堆積，可能造成故障。

消息丟失

消息丟失，業(yè)務是否兼容，是否有補償或者監(jiān)控機制。

消息爭用

如果是集群模式，同一topic下新增新的消費組，但是沒有申請新的group，導致一條消息投遞過來，多個消費組爭搶。

比如開發(fā)為了省事，預發(fā)和線上同一個topic，消費組的group也一樣，上線后，可能存在有效消息被預發(fā)消費組消費了。

MQ比落庫快

比如某接口A，新增一條數(shù)據(jù)后會同步更新DB和發(fā)送MQ給服務B，服務B收到消息后查詢DB這條數(shù)據(jù)。曾經發(fā)現(xiàn)了收到消息卻查不到數(shù)據(jù)的情況，因為數(shù)據(jù)庫更新速度沒有MQ快，后來改成異步了。

以上就是盤點MQ中的異常測試的詳細內容，更多關于MQ異常測試的資料請關注腳本之家其它相關文章！

最新評論