什么是消息中間件？通過提供某種規范實現在不同系統之間傳遞語義準確的消息。專注于數據的發送和接收，利用高效可靠的異步消息傳遞機制的集成分布式系統。什么是MQ?

MQ全稱為Message Queue, 消息隊列(MQ)是應用程序“對”應用程序的通信方法，也是消息中間件的一種。

MQ：生產者往消息隊列中寫消息，消費者可以讀取隊列中的消息。

消息隊列的應用場景

a. 異步處理：比如訂單狀態處理完畢的回調通知；

b. 系統間應用解耦：前一個系統將要處理的內容放入消息隊列，就不再關心后續的其他操作了，后面的系統獲取消進行消費；

c. 流量削鋒：避免因流量過大，導致流量暴增，海量消息堆積，應用掛掉；

d. 日志處理：通過隊列進行日志處理；

e. 消息通訊：消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。

基本概念

1

消息模型

點對點模型(P2P)：

在P2P模型中，有下列概念：消息隊列(Queue)、發送者(Sender)、接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到它們被消費或超時。

·每個消息只有一個消費者(Consumer)(即一旦被消費，消息就不再在消息隊列中)。

·發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之后，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列。

·接收者在成功接收消息之后需向隊列應答成功。

如果希望發送的每個消息都應該被成功處理的話，那么你需要P2P模型。

發布-訂閱模型(Pub/Sub)：

在Pub/Sub模型中，有下列概念：主題(Topic)、發布者(Publisher)、訂閱者(Subscriber)。客戶端將消息發送到主題。多個發布者將消息發送到Topic，系統將這些消息傳遞給多個訂閱者。

·每個消息可以有多個消費者

·發布者和訂閱者之間有時間上的依賴性。針對某個主題(Topic)的訂閱者，它必須創建一個訂閱之后，才能消費發布者的消息，而且，為了消費消息，訂閱者必須保持運行的狀態。

訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活(運行)，它也能接收到發布者的消息。

如果希望發送的消息可以不被做任何處理、或者被一個消費者處理、或者可以被多個消費者處理的話，那么可以采用Pub/Sub模型。

2

交互原理

Nameserver做什么？

Namesrv是主要做路由服務(狀態服務器)，無狀態可集群橫向擴展。broker同時向多個Namesrv機器上報broker機器的實時狀態信息、topic消息隊列路由信息、broker基礎信息、集群信息，從而達到數據熱備份的作用。Producer發送消息的時候，先請求nanesrv獲取topic路由信息，然后根據topic路由信息路由到broker(topic是存儲在broker)。Consumer消費消息的時候同樣先請求nanesrv獲取topic路由信息，然后根據topic路由信息路由到broker。

Broker做什么？

消息中轉角色，負責存儲消息，轉發消息。broker部署相對復雜，分為master和slave，一個master可以對應多個slave，但一個slave只能對應一個master(支持異步復制和半同步復制)。master可以集群部署，通過同樣的ClusterName來區分，同一個集群中的BrokerName不能一樣。每個broker與namesrv集群中的所有節點建立長連接，定時發送心跳信息(30秒)，注冊topic等信息到所有namesrv。

Producer

Producer 與Name Server 集群中的其中一個節點(隨機選擇)建立長連接，定期從Name Server 取Topic 路由信息，并向提供Topic 服務的Master 建立長連接，且定時向Master 發送心跳，Slave會同步Master的信息。Producer 完全無狀態，可集群部署。

Consumer

Consumer與Name Server 集群中的其中一個節點(隨機選擇)建立長連接，定期從Name Server 取Topic 路由信息，并向提供Topic 服務的Master、Slave 建立長連接，且定時向Master、Slave 發送心跳。Consumer既可以從Master 訂閱消息，也可以從Slave 訂閱消息，訂閱規則由Broker 配置決定。

Broker集群

一個Master下面可以掛載多個Slave，同一Master下的多個Slave通過指定不同的BrokerId來區分。

3

測試內容及問題排查方法

Q1：MQ是否能保證消息不重復？

1、絕大多數情況下，消息是不重復的。作為一款分布式消息中間件，在網絡抖動、應用處理超時等異常情況下，無法保證消息不重復，但是能保證消息不丟失；

2、需要業務方自己實現去重邏輯，不推薦使用msgid來做去重，因為msgid在絕大部分情況下，是不會重復，不排除極端情況可能會出現重復，或者多個集群之間出現重復msgid；

3、可以使用訂單編號等唯一的作為唯一標識來去重。

Q2：MQ未被消費、消息發送了，但是沒有收到怎么查詢？

MQ提供了多種消息查詢方式：

1、使用Topic按時間范圍進行查詢，可以查詢到一段時間內某Topic收到的所有消息；

2、使用Topic和MessageID對消息進行精準查詢；

3、使用Topic和MessageKey較為精準地查詢具有相同MessageKey的一類消息。

Q3：MQ消費失敗如何重新消費消息？

1、消費業務邏輯代碼如果返回ConsumeConcurrentlyStatus.RECONSUME_LATER，或者NULL，或者拋出異常，消息都會走重試流程，默認重試16次(重試次數可以自定義)，如果重試16次后，仍然失敗，則消息丟棄；

2、消息重試間隔可以通過context控制，如果不控制，會越來越長。

Q4：MQ消費失敗、容器環境消息消費失敗怎么排查？

1.、檢查訂閱關系是否正確，topic是否正確；

2、檢查消費組狀態是否正常；

sh[用戶名]consumerConnection-n127.0.0.1:9876-g消費組名

sh[用戶名]consumerProgress-n127.0.0.1:9876-g消費組名

3、檢查生產者機器和消費者機器的地址解析是否為容器組mq地址；在docker管理平臺，模板配置中進行配置及查看；

4、檢查消費者服務器是否配置了外網地址，導致消息發送到基準環境；

5、確認生產者已生產消息。

Q5：簡單的日志查詢

通過MQ服務器上log日志，查詢put及pull的記錄。

Q6：MQ消費先于同步返回

一般采用加鎖機制處理。

4

命名規范

Topic命名規范：

1、所有Topic必須使用T_開頭，Topic中包含業務系統，可以唯一區分業務。

2、必須填寫tag，同一Topic用不同的tag區分，全部大寫。消費者通過Topic+tag消費消息。

3、使用運維平臺查詢Topic是否存在，存在需要考慮是否要更換Topic。

例：topic：T_LOAN_PRODUCT

tag：T_CANCEL_BORROW或T_SUBMIT_RESALE[topic+tag匹配消費消息]

消費組命名規范：

1、消費組必須以S_開頭，包含業務系統，全部大寫。同一Topic可以被多個消費組消費。

2、使用運維平臺查詢消費組是否存在，存在需要考慮是否要更換消費組。

例：c-group-id:S_PFD_T_ATM

生產組命名規范：

生產者必須使用P_開頭,包含業務系統，全部大寫，不同的系統禁止使用同一個組名。

例：p-group-id:P_PAYFUND

鏈接：https://zhuanlan.zhihu.com/p/99616947

本文為51Testing經授權轉載，轉載文章所包含的文字來源于作者。如因內容或版權等問題，請聯系51Testing進行刪除

推薦閱讀

點擊閱讀?從業多年測試工程師總結，大廠面試必問問題就是這些

點擊閱讀?那些年！測試工程師面試時都遇到過哪些問題呢？

點擊閱讀?中高級測試工程師面試題，助你一臂之力！

點擊閱讀?漲薪失敗，我是如何從3500加班狗做到測試開發工程師的？

點擊閱讀?軟件測試工程師面試如何做好自我介紹？

戳

總結

以上是生活随笔為你收集整理的js能订阅mq吗_测试工程师，必须了解的MQ知识！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。