消息隊(duì)列之九問(wèn)九答

問(wèn)題1 為什么要用消息隊(duì)列呀？

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

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

再次，如果不用mq，高峰期的時(shí)候，大量請(qǐng)求打入系統(tǒng)，萬(wàn)一系統(tǒng)的處理邏輯涉及到數(shù)據(jù)庫(kù)，那么很容易掛掉，高峰期一過(guò)，系統(tǒng)壓力又大大減小。<小知識(shí)，一般的mysql，一般能扛到每秒2000個(gè)請(qǐng)求> 所以使用mq削峰，系統(tǒng)慢慢從mq中拉取數(shù)據(jù)作處理，保證高峰期系統(tǒng)也不會(huì)掛掉，雖然有可能堆積消息，但是高峰期一過(guò)，請(qǐng)求就會(huì)被快速處理掉的。

問(wèn)題2 消息隊(duì)列的優(yōu)點(diǎn)和缺點(diǎn)？

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

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

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

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

問(wèn)題3 消息隊(duì)列都有哪些類(lèi)型，分別有什么優(yōu)缺點(diǎn)呀？

（1）、常見(jiàn)的消息隊(duì)列有 kafaka、activemq、rabbitmq、rocketmq （2）、消息隊(duì)列的比較

問(wèn)題4 如何保證消息隊(duì)列的高可用呀？

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

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

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

問(wèn)題5 如何保證消息隊(duì)列的冪等性？

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

問(wèn)題6 如何保證消息的可靠傳輸？

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

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

一般的開(kāi)發(fā)過(guò)程，只要接入了mq，都會(huì)寫(xiě)一個(gè)補(bǔ)單腳本做對(duì)賬。

問(wèn)題7 如何保證消息的順序性？

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

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

問(wèn)題8 如何解決消息隊(duì)列的延時(shí)以及過(guò)期失效問(wèn)題呀？

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

如果大量積壓，又無(wú)法立刻解決的話(huà)，就開(kāi)啟丟消息的模式，后續(xù)低峰期的時(shí)候，把數(shù)據(jù)補(bǔ)償回來(lái)。

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

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

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

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

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

原文鏈接：https://blog.csdn.net/cfy1024/article/details/105753042

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