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

答：如下圖所示，外呼系統(tǒng)需要將外呼結(jié)果發(fā)送給業(yè)務(wù)系統(tǒng)，如果采用rpc的調(diào)用方式；則帶來的后果， 首先，1、外呼系統(tǒng)與業(yè)務(wù)系統(tǒng)嚴重耦合，多個業(yè)務(wù)系統(tǒng)需要外呼系統(tǒng)傳輸數(shù)據(jù)，如果有接口調(diào)用的方式，那無論是接入新的業(yè)務(wù)還是撤掉業(yè)務(wù)，都需要改動代碼；

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

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

問題2 消息隊列的優(yōu)點和缺點？

優(yōu)點：如1所說，可以解耦、低耗時、削峰 缺點：

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

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

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

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

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

特性activemqrabbitmqrocketmqkafka

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

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

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

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

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

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

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

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

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

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

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

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

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

把需要保證順序的數(shù)據(jù)放在內(nèi)存隊列里，然后每個線程處理一個隊列，這樣就可以保證順序執(zhí)行啦。

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

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

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

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

1、可伸縮性，支持快速擴容，增加吞吐量和容量?？蓞⒖糼afka的設(shè)計方案 broker -> topic -> partion，如果需要擴容，增加partion和機器即可。

2、落磁盤，防止數(shù)據(jù)丟失。

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

4、保證數(shù)據(jù)的0丟失。可結(jié)合靈魂拷問1-8回答。

---

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

1.微服務(wù)實戰(zhàn)系列

2.springboot從入門到精通

3.java入門到精通

4.中間件等

5.程序人生

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。