問題1 為什么要用消息隊列呀？

答：如下圖所示，外呼系統需要將外呼結果發送給業務系統，如果采用rpc的調用方式；則帶來的后果， 首先，1、外呼系統與業務系統嚴重耦合，多個業務系統需要外呼系統傳輸數據，如果有接口調用的方式，那無論是接入新的業務還是撤掉業務，都需要改動代碼；

2、如果業務系統掛掉/訪問超時，要保證不能影響其他業務系統；所以：需要利用消息隊列解耦，這樣做的好處：外呼系統和業務系統解耦，業務系統有需要，消費mq即可 外呼系統也無需關注業務系統的消費情況啦其次，如果采用rpc調用方式(同步)，則總體耗時 = 在外呼系統的耗時 + 在審核系統的耗時 + 在天網的耗時。。總體耗時過長， 使用mq異步化之后，性能優化啦，總耗時 = 外呼系統的耗時 + 發送mq的耗時。

再次，如果不用mq，高峰期的時候，大量請求打入系統，萬一系統的處理邏輯涉及到數據庫，那么很容易掛掉，高峰期一過，系統壓力又大大減小。 所以使用mq削峰，系統慢慢從mq中拉取數據作處理，保證高峰期系統也不會掛掉，雖然有可能堆積消息，但是高峰期一過，請求就會被快速處理掉的。

問題2 消息隊列的優點和缺點？

優點：如1所說，可以解耦、低耗時、削峰 缺點：

(1)、系統的可用性降低，mq一旦掛掉，提供者沒辦法發送消息了，消費者也無法接收到數據了

(2)、系統的復雜性提高，引入了mq，就要考慮消息重復、消息冪等、消息丟失、消息延遲、消息堆積、消息順序錯亂等問題?

(3)、系統的一致性問題，如果消費失敗，那么有可能導致提供者與消費者狀態不一致的問題

問題3 消息隊列都有哪些類型，分別有什么優缺點呀？

(1)、常見的消息隊列有 kafaka、activemq、rabbitmq、rocketmq (2)、消息隊列的比較

特性activemqrabbitmqrocketmqkafka

單機吞吐量	萬級	萬級	10萬級 支撐高吞吐量	10萬級 大數據類，實時數據計算，日志采集
topic數量對吞吐量的影響			topic達到幾百幾千時，吞吐量會稍微的下降	topic達到幾百幾千時，吞吐量會稍微的下降
時效性	ms	微妙	ms	ms
可用性	高 主從架構	高 主從架構	分布式架構	非常高，分布式架構，多個副本，少數機器宕機，數據不會丟失
消息可靠性	有較低的概率會丟數據		配置參數，可達到0丟失	配置參數，可達到0丟失
功能支持	mq領域的功能完備	erlang開發，并發能力好，性能好，耗時低	功能完備，分布式，擴展性好	功能簡單，大數據領域采用較多
總結	小規模吞吐量，非常成熟，功能強大，在業內大量公司及項目中應用，偶爾會丟數據，但官方維護較少，主要可以基于解耦和異步，不太實用高吞吐量的大規規模場景	erlang開發，并發能力好，性能好，耗時低，開源提供管理界面，中小型企業可選，社區活躍，缺點是erlang源碼不好懂，掌控力較弱，集群動態擴展麻煩	接口簡單易用，阿里開源，品質有保障，性能好，分布式擴展方便，只是大規模topic，java代碼源碼可讀，但是萬一項目被阿里拋棄，需要自己維護	功能較少，吞吐量較高，易擴展，適合大數據實時計算和日志采集

問題4 如何保證消息隊列的高可用呀？

(1)rabbitmq 非分布式 a、單機模式，只有一臺機器。b、普通集群模式 rabbitmq 有三臺機器，只有一臺機器存了元數據和所有數據，如果有消費者需要消費數據，訪問了a或c，那么a或c就會根據其元數據路由到b機器上。優點：可隨便路由到某臺機器，皆可訪問；缺點：集群內部產生大量的數據傳輸，且萬一某一個掛掉，則無法找回數據。c、鏡像集群模式 在管理控制臺新增一個策略，制定所有節點同步數據創建queue的時候，都選擇該策略。每個rabbitmq節點上都有queue 元數據 和 所有數據。這樣，生產者往queue里寫數據，rabbitmq就會自動同步到其他節點上去，每個節點都有queue的完整鏡像，消費者可從任一一個節點去消費，如果出現宕機，可以從其他節點去獲取數據?

(2)rocketmq 分布式 采用 多master多slave模式 同步雙寫模式?

(3)kafka：純分布式架構的mq。每個topic分為不同的partion，放在不同的機器上，所以每一臺機器上都有部分topic數據，每個partion只會被一個消費者消費。高可用保證：replica 副本機制 每份數據都會有多個副本，會選舉一個為leader，其他為follow，對于同一個topic下的partion，只有leader才可以提供讀寫。如果leader宕機，kafka會感知到，那么會重新選舉新的follow為leader。

問題5 如何保證消息隊列的冪等性？

冪等性：同樣的數據只消費一次。為什么會發生消息重復消費的情況？如Kafka，如果在消費者準備提交的時候，被重啟了，那么kafka是不知道消費者準確的消費到了哪條數據，就有可能會出現重復消費。總之，就是如果mq和消費者的信息不對等了，就會出現這個問題咯。那么，如何解決呢？1、如果是庫表類的操作，用業務主鍵來去重；2、或者可以利用redis、內存等，用一個衛衣標識來保證消息的冪等性。例如：外呼系統中，業務系統拿到結果要落庫表，可以用callid作為冪等性的保證。

問題6 如何保證消息的可靠傳輸？

1、rabbitmq 生產者->rabbitmq->消費者 可能會丟消息的情況：a、消息因為網絡傳輸等原因沒到mq就丟了。b、mq內部出錯了，沒保存下來。c、mq保存下來了，還沒消費呢，mq掛了，被丟了。d、消費者消費到了數據，還沒來得及處理，掛掉了，但是mq以為消費完了。如何解決呢？a的解決方案1：rabbitmq支持事物，生產者發消息之前開啟一個事務，如果收到異常，就證明沒發送成功，那么可以回滾，再重試發送；缺點是同步機制，需要等結果，比較耗時。a的解決方案2：開啟confirm模式，生產者提供回調接口，mq接收到了消息去回調該接口通知接收是否成功。b和c的解決方案：把消息持久化到磁盤上。queue設置成持久化，消息的delivery mode 設置成2 d的解決方案：關閉消費者的autoack，不再自動告訴mq，OK了，而是等處理完了再告訴。

2、kafka 生產者->kafka->消費者 a、消費端弄丟數據，kafka自動提交offset，讓kafka以為消費完了。解決方案，放棄自動提交，處理完之后再提交。b、kafka本身丟數據。設置四個參數。topic 的 replication factor > 1 ，每個partion至少有2個副本 min.insync.replicas >1 , 要求每一個leader至少有一個follow跟他保持聯系 produce ack=all 每條數據必須寫入到副本之后，才算寫成功 retires = max(很大的值)，如果寫入失敗，就進入無限重試，保證leader和follow切換時，不會丟失數據。

一般的開發過程，只要接入了mq，都會寫一個補單腳本做對賬。

問題7 如何保證消息的順序性？

1、rabbitmq 為何會消息錯亂呢？一個queue的數據被多個消費者消費，這時候就有可能會出現順序錯亂的情況。解決方案，多創造幾個queue，把需要保證順序的數據放在一個queue里，每一個queue只有一個消費者。2、kafkakafka的partion只能有一個消費者，但是如果消費者內部是多線程并發處理的，那么是可能會出現順序錯亂的問題。

把需要保證順序的數據放在內存隊列里，然后每個線程處理一個隊列，這樣就可以保證順序執行啦。

問題8 如何解決消息隊列的延時以及過期失效問題呀？

快速擴容呀。具體的方案可參考：(1)、新建一個topic，創建10倍的partion， (2)、消費者消費到數據之后，啥都不干，就只往新的topic里寫數據， (3)、申請partion數量的機器，去處理里面的數據。

如果大量積壓，又無法立刻解決的話，就開啟丟消息的模式，后續低峰期的時候，把數據補償回來。

問題9 ?如何設計消息隊列中間件？

1、可伸縮性，支持快速擴容，增加吞吐量和容量。可參考kafka的設計方案 broker -> topic -> partion，如果需要擴容，增加partion和機器即可。

2、落磁盤，防止數據丟失。

3、可用性，leader和follow的模式

4、保證數據的0丟失。可結合靈魂拷問1-8回答。

---

原文鏈接：https://blog.csdn.net/cfy1024/article/details/105753042
END/往期推薦:

1.微服務實戰系列

2.springboot從入門到精通

3.java入門到精通

4.中間件等

5.程序人生

更多信息請關注公眾號：「軟件老王」，關注不迷路，軟件老王和他的IT朋友們，分享一些他們的技術見解和生活故事。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的ibm mq并发访问队列_消息队列之九问九答的全部內容，希望文章能夠幫你解決所遇到的問題。

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