一、什么是 MQ
MQ全稱是 Message Queue，本質上是個隊列，原則還是先進先出，只不過隊列里存放的元素是一條條 Message 。
工作中常見被用於上下游傳遞消息，實現一種跨進程的通信。這樣一來，要發送消息的上游服務只依賴 MQ 即可，與下游服務解耦，我覺得可以理解成中介。
二、MQ 的作用
1. 流量削峰
舉個栗子，這里有一個訂單系統處理用戶下單的業務邏輯。這個系統的服務能力假設為 1S 處理1萬次訂單，那么正常來說，不超過1萬次對它來說都沒問題。但是，如果到了用戶下單的高峰期，這時候的單量可能就要超過系統服務能力。
這時候可以加入 MQ，把1s內下的訂單進行排隊，分散在一段時間內處理，雖然說會導致有些用戶會在幾秒之后才能收到下單成功，但是比起不能下單還是要好很多了。
2. 應用解耦
現在有個電商應用，里面包含了好多個子系統：訂單系統、庫存系統、物流系統、支付系統等。
先看下耦合在一起的情況，當用戶創建訂單后，如果后面任何一個子系統出現了故障，都會造成用戶的下單操作異常。
現在加上 MQ 后，訂單系統的工作完成后，接下來的事情就轉交給MQ了。MQ 會分配消息給其他的3個系統，直到3個系統執行完成。如果存在其中有不能完成的系統，隊列會監督它繼續完成。比如物流系統壞了，但是訂單系統不受影響，用戶感覺不出來有異常，依舊可以看到成功下單的提示。當物流系統恢復正常以后，繼續處理訂單信息即可，從而提升了整個系統的可用性。
3. 異步處理
在生產中，有些服務間的調用是異步的。A 調用 B，但是 B 需要花費一段時間來處理。沒有 MQ 的時候通常這樣處理：
- A 輪詢的調用 B的查詢，看看結果是不是處理好了。
- A 提供一個callback 回調接口，B 執行好了調用這個api接口通知 A。
加入 MQ 后，這時 A 再調用 B 后，只需要監聽 B 處理完成的消息即可。當 B 處理完成后，會發送一條消息給 MQ，然后 MQ 會把消息轉發給 A。所以，現在 A 既不用輪詢 B，也不用提供回調api
三、MQ 的缺點
MQ 這么好用，難道就沒有缺點嗎？ 有。
- 首先，在系統里加入了一個中間件服務，無疑是會增加了系統復雜度。
- 如果 MQ 宕機了，不能用了，那么后面的流程也沒法處理了。
- 存在一致性問題。比如訂單系統創建好了訂單，發給下游的消息沒發出去，那么就產生了臟數據。再比如，先發送了訂單的消息，再去創建訂單，如果創建失敗了，消息卻發送成功了，此時下游以為已經創建好了訂單。
- 其他問題，比如消息丟失，重復發送相同消息，消息被其他系統消費，消息大量積壓等等，都需要我們有對應方案解決。
對於一致性問題，在 testerhome 有看到過一位大佬分享的經驗：
首先，消費者在消費成功后通過同步請求或者另一條 mq 隊列，反饋給生產者，生產者更新自己內部這條消息的狀態為已處理。
同時生產者內置一個定時任務，查看內部所有待處理消息是否超時，如果超時，進行自動補償。補償大概步驟是：
- 發起 http 同步查詢給消費者，確認消費者是否有消費
- 若消費者反饋已消費，直接更新生產者自身內部消息狀態
- 若消費者反饋未收到，則進行預警，人工介入處理（一般不會直接重發，因為重發有可能引發更嚴重的問題，如加劇 mq 消息堆積的情況）
四、常見 MQ 分類
1. ActiveMQ
Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，少量代碼就可以高效地實現高級應用場景。
優點：
- 單機吞吐量： 萬級。
- 時效性： ms級。
- 可用性：高。
- 消息可靠性：較低概率出現丟失數據。
缺點
官方社區現在對於 ActiveMQ 5.x的版本維護越來越少，高吞吐量場景較少使用。
2. Kafka
Apache下的一個子項目，使用scala實現的一個高性能分布式Publish/Subscribe消息隊列系統。尤其在大數據上是個殺手鐧，吞吐量在百萬級，在數據采集、傳輸、存儲的過程中發揮舉足輕重的作用。
優點
- 單機吞吐量： 百萬級。
- 時效性： ms級。
- 可用性：非常高。
- 消息可靠性：可配置 0 丟失。
- 分布式：一個數據有多個副本，少數機器宕機也不會丟失數據。
缺點
- 單機超過64個隊列/分區，CPU會明顯變高，隊列越多越高，發送消息響應時間變長。
- 消費失敗不支持重試。
Kafka主要特點是基於PULL的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日志收集和傳輸，適合產生大量數據的互聯網服務的數據收集業務。
3. RocketMQ
阿里系下開源的一款分布式、隊列模型的消息中間件，是阿里參照kafka設計思想使用java實現的一套MQ，並做了自己的改進。被阿里廣泛的應用在訂單、交易、充值、流計算、消息推送、日志流處理等場景。
優點
- 單機吞吐量： 十萬級。
- 時效性： ms級。
- 可用性：非常高。
- 消息可靠性：可配置 0 丟失。
- 分布式：支持。
- 擴展性好，支持10億級別的消息堆積。
- 源碼是java，有利於定制。
缺點
支持的語言不多，主要是java，C++還不成熟。社區活躍也一般，沒有在 MQ 核心中實現 JMS 等接口，有些系統需要遷移則要修改大量代碼。
RocketMQ 天生為了金融互聯網而生，對於可靠性要求很高的場景，比如電商里的扣款，它更值得信賴。
4. RabbitMQ
使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。
優點
- 單機吞吐量： 萬級。
- 時效性：μs級。
- 可用性：高。
- 消息可靠性：基本不丟失。
- 支持多語言。
- 社區活躍度高，更新頻率高
缺點
商業版需要付費，學習成本較高。
RabbitMQ 性能好，時效性強，管理界面也很友好。如果數據量沒那么大，中心型業務可以優先選擇功能完備的 RabbitMQ。
五、MQ 的組成
1. 角色
- Broker：消息服務器，提供消息核心服務
- Producer：消息生產者，業務的發起方，負責生產消息傳輸給broker。
- Consumer：消息消費者，業務的處理方，負責從broker獲取消息並進行業務邏輯處理。
- Topic：主題，發布訂閱模式下的消息統一匯集地，不同生產者向topic發送消息，由MQ服務器分發到不同的訂閱者，實現消息的廣播。
- Queue：隊列，點對點模式下，特定生產者向特定queue發送消息，消費者訂閱特定的queue完成指定消息的接收。
- Message：消息體，根據不同通信協議定義的固定格式進行編碼的數據包，來封裝業務數據，實現消息的傳輸。
2. MQ 消息模式
1）點對點模式
使用 queue 作為通信載體，消息生產者生產消息發送到 queue 中，然后消息消費者從 queue 中取出並且消費消息。
- 消息被消費以后，queue中不再存儲，所以消息消費者不可能消費到已經被消費的消息。
- Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。
2）發布訂閱模式
使用topic作為通信載體，1個生產者可以對應多個消費者。消息生產者（發布）將消息發布到topic中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不同，發布到topic的消息會被所有訂閱者消費。
就像你發了個朋友圈，你的朋友們都可以看到。
六、MQ 測試需要的關注點
1. 對於生產者
- 生成的數據格式是否跟定義的一致
- 數據是否有成功推送到隊列里
- 數據是否有成功推動到對應的 topic
- 推送失敗時如何處理
- 重復推送同一條數據，如何處理
- 不同順序推送消息，注意隊列優先級
- 推消息耗時，隊列容量達到上限，無法推送后如何處理
2. 對於消費者
- 消費的消息是否來自訂閱的 topic
- 消息被消費了，是否有清除
- 生產者推送過快，消費速度過慢（堵塞），會如何
- 無法消費沒訂閱的 topic 消息
- 生產者推送消息后，消費者接受到的消息內容跟生產者推的一致
- 如何處理重復消息，比如冪等
- 處理超時
- 消息處理失敗
- 消費消息的優先級是否跟推的一致
- 消費消息耗時
- 消費者宕機，消息堆積，無人處理，會如何處理
- 是否能正常消費消息
3. 對於隊列
- 宕機恢復后，消息是否丟失
- 宕機預案，多久能恢復，如果無法恢復的預案
- 不同的消息格式，是否能正常識別及轉發
具體關注點，其實還要看具體業務來，這些都可以做些了解，如果有涉及到與MQ交互的，可以從多方面去考慮，增加測試覆蓋。
最后本文參考文章：
https://testerhome.com/articles/30382
https://blog.csdn.net/wender/article/details/86317970
https://www.baidu.com/