[[426772]]

本文轉(zhuǎn)載自微信公眾號「微觀技術(shù)」，作者 微觀技術(shù)。轉(zhuǎn)載本文請聯(lián)系微觀技術(shù)公眾號。

大家好，我是 Tom哥~

馬上要開啟國慶小長假了，祝大家節(jié)日快樂，吃喝玩樂走起~

為了便于大家查找問題，了解全貌，整理個(gè)目錄，我們可以快速全局了解關(guān)于消息隊(duì)列，面試官一般會(huì)問哪些問題。

本篇文章的目錄：

消息隊(duì)列的應(yīng)用場景?

答案：1、異步處理 2、流量削峰填谷 3、應(yīng)用解耦 4、消息通訊

• 異步處理。將一個(gè)請求鏈路中的非核心流程，拆分出來，異步處理，減少主流程鏈路的處理邏輯，縮短RT，提升吞吐量。如：注冊新用戶發(fā)短信通知。
• 削峰填谷。避免流量暴漲，打垮下游系統(tǒng)，前面會(huì)加個(gè)消息隊(duì)列，平滑流量沖擊。比如：秒殺活動(dòng)。生活中像電源適配器也是這個(gè)原理。
• 應(yīng)用解耦。兩個(gè)應(yīng)用，通過消息系統(tǒng)間接建立關(guān)系，避免一個(gè)系統(tǒng)宕機(jī)后對另一個(gè)系統(tǒng)的影響，提升系統(tǒng)的可用性。如：下單異步扣減庫存
• 消息通訊。內(nèi)置了高效的通信機(jī)制，可用于消息通訊。如：點(diǎn)對點(diǎn)消息隊(duì)列、聊天室。

常用的消息框架有哪些?

答案：ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaQ，RocketMQ、Pulsar 等

MQ技術(shù)選型?

答案：對比了 Kafka、RocketMQ 、Pulsar 三個(gè)框架，時(shí)耗、吞吐量、可靠性、事務(wù)、副本同步策略、多租戶、動(dòng)態(tài)擴(kuò)容、故障恢復(fù)等評估指標(biāo)。

消息模型有哪些?

答案：1、點(diǎn)對點(diǎn)模式 2、發(fā)布/訂閱模式

如何保證 MQ 消息不丟失?

答案：在了解消息中間件的運(yùn)作模式后，主要從三個(gè)方面來考慮這個(gè)問題：

1、生產(chǎn)端，不丟失消息

2、MQ服務(wù)端，存儲(chǔ)本身不丟失消息

3、消費(fèi)端，不丟失消息

如何解決消息的重復(fù)消費(fèi)?

答案：生產(chǎn)端為了保證消息發(fā)送成功，可能會(huì)重復(fù)推送(直到收到成功ACK)，會(huì)產(chǎn)生重復(fù)消息。但是一個(gè)成熟的MQ Server框架一般會(huì)想辦法解決，避免存儲(chǔ)重復(fù)消息(比如：空間換時(shí)間，存儲(chǔ)已處理過的message_id)，給生產(chǎn)端提供一個(gè)冪等性的發(fā)送消息接口。

但是消費(fèi)端卻無法根本解決這個(gè)問題，在高并發(fā)標(biāo)準(zhǔn)要求下，拉取消息+業(yè)務(wù)處理+提交消費(fèi)位移需要做事務(wù)處理，另外消費(fèi)端服務(wù)可能宕機(jī)，很可能會(huì)拉取到重復(fù)消息。

所以，只能業(yè)務(wù)端自己做控制，對于已經(jīng)消費(fèi)成功的消息，本地?cái)?shù)據(jù)庫表或Redis緩存業(yè)務(wù)標(biāo)識，每次處理前先進(jìn)行校驗(yàn)，保證冪等。

如何保證 MQ消息是有序的?

答案：有些業(yè)務(wù)有上下文要求，比如：電商行業(yè)的下單、付款、發(fā)貨、確認(rèn)收貨，每個(gè)環(huán)節(jié)都會(huì)發(fā)送消息。而消費(fèi)端拉取并消費(fèi)消息時(shí)，也是希望按正常的狀態(tài)機(jī)流程進(jìn)行。所以對消息就有了順序要求。解決思路：

1、該topic強(qiáng)制采用一個(gè)分區(qū)，所有消息放到一個(gè)隊(duì)列里，這樣能達(dá)到全局順序性。但是會(huì)損失高并發(fā)特性。

2、局部有序，采用路由機(jī)制，將同一個(gè)訂單的不同狀態(tài)消息存儲(chǔ)在一個(gè)分區(qū)partition，單線程消費(fèi)。比如Kafka就提供了一個(gè)接口擴(kuò)展org.apache.kafka.clients.Partitioner，方便開發(fā)人員按照自己的業(yè)務(wù)場景來定制路由規(guī)則。

消息堆積如何處理?

答案：主要是消息的消費(fèi)速度跟不上生產(chǎn)速度，從而導(dǎo)致消息堆積。解決思路：

1、可能是剛上線的業(yè)務(wù)，或者大促活動(dòng)，流量評估不到位，這時(shí)需要增加消費(fèi)組的機(jī)器數(shù)量，提升整體消費(fèi)能力

2、也可能是消費(fèi)端的問題，正常情況，一條消息處理需要10ms，但是優(yōu)化不到位或者線上bug，現(xiàn)在要500ms，那么消費(fèi)端的整體處理速度會(huì)下降50倍。這時(shí)，我們就要針對性的排查業(yè)務(wù)代碼。Tom哥之前帶的團(tuán)隊(duì)就有小伙伴出現(xiàn)這個(gè)問題，當(dāng)時(shí)是數(shù)據(jù)庫的一條sql沒有命中索引，導(dǎo)致單條消息處理耗時(shí)拉長，進(jìn)而導(dǎo)致消息堆積，線上報(bào)警，不過憑我們豐富的經(jīng)驗(yàn)，很快就定位解決了。

如何保證數(shù)據(jù)一致性問題?

答案：為了解耦，引入異步消息機(jī)制。先進(jìn)行本地?cái)?shù)據(jù)庫操作，處理成功后，再發(fā)送MQ消息，由消費(fèi)端進(jìn)行后續(xù)操作。比如：電商訂單下單成功后，要通知扣減庫存。

這兩者一定要保證事務(wù)操作，否則就會(huì)出現(xiàn)數(shù)據(jù)不一致問題。這時(shí)候，我們就需要引入事務(wù)消息來解決這個(gè)問題。

另外，在消費(fèi)環(huán)節(jié)，也可能出現(xiàn)數(shù)據(jù)不一致情況。我們可以采用最終一致性原則，增加重試機(jī)制。

事務(wù)消息是如何實(shí)現(xiàn)?

答案：

• 1、生產(chǎn)者先發(fā)送一條半事務(wù)消息到MQ
• 2、MQ收到消息后返回ack確認(rèn)
• 3、生產(chǎn)者開始執(zhí)行本地事務(wù)
• 4、if 本地事務(wù)執(zhí)行成功，發(fā)送commit到MQ;失敗，發(fā)送rollback
• 5、如果MQ?時(shí)間未收到生產(chǎn)者的二次確認(rèn)commit或rollback，MQ對生產(chǎn)者發(fā)起反向回查
• 6、生產(chǎn)者查詢事務(wù)執(zhí)行最終狀態(tài)
• 7、根據(jù)查詢事務(wù)狀態(tài)，再次提交二次確認(rèn)

MQ框架 如何實(shí)現(xiàn)高吞吐量?

答案：

1、消息的批量處理

2、消息壓縮，節(jié)省傳輸帶寬和存儲(chǔ)空間

3、零拷貝

4、磁盤的順序?qū)懭?/p>

5、page cache 頁緩存，由操作系統(tǒng)異步將緩存中的數(shù)據(jù)刷到磁盤，以及高效的內(nèi)存讀取

6、分區(qū)設(shè)計(jì)，一個(gè)邏輯topic下面掛載N個(gè)分區(qū)，每個(gè)分區(qū)可以對應(yīng)不同的機(jī)器消費(fèi)消息，并發(fā)設(shè)計(jì)。

Kafka 為什么不支持讀寫分離?

答案：我們知道，生產(chǎn)端寫入消息、消費(fèi)端拉取消息都是與leader 副本交互的，并沒有像mysql數(shù)據(jù)庫那樣，master負(fù)責(zé)寫，slave負(fù)責(zé)讀。

這種設(shè)計(jì)主要是從兩個(gè)方面考慮：

1、數(shù)據(jù)一致性。一主多從，leader副本的數(shù)據(jù)同步到follower副本有一定的延時(shí)，因此每個(gè)follower副本的消息位移也不一樣，而消費(fèi)端是通過消費(fèi)位移來控制消息拉取進(jìn)度，多個(gè)副本間要維護(hù)同一個(gè)消費(fèi)位移的一致性。如果引入分布式鎖，保證并發(fā)安全，非常耗費(fèi)性能。

2、實(shí)時(shí)性。leader副本的數(shù)據(jù)同步到follower副本有一定的延時(shí)，如果網(wǎng)絡(luò)較差，延遲會(huì)很嚴(yán)重，無法滿足實(shí)時(shí)性業(yè)務(wù)需求。

綜上考慮，讀寫操作都是針對 leader 副本進(jìn)行的，而 follower 副本主要是用于數(shù)據(jù)的備份。

MQ框架如何做到高可用性?

答案：以Kafka框架為例，其他的MQ框架原理類似。

Kafka 由多個(gè) broker 組成，每個(gè) broker 是一個(gè)節(jié)點(diǎn)。你創(chuàng)建一個(gè) topic，這個(gè) topic 可以劃分為多個(gè) partition，每個(gè) partition 存放在不同的 broker 上，每個(gè) partition 存放一部分?jǐn)?shù)據(jù)，每個(gè) partition 有多個(gè) replica 副本。

寫的時(shí)候，leader 會(huì)負(fù)責(zé)把數(shù)據(jù)同步到所有 follower 上去，讀的時(shí)候就直接讀 leader 上的數(shù)據(jù)即可。

如果某個(gè) broker 宕機(jī)了，沒事兒，那個(gè) broker 上面的 partition 在其他機(jī)器上都有副本，此時(shí)會(huì)從 follower 中重新選舉一個(gè)新的 leader 出來，大家繼續(xù)讀寫那個(gè)新的 leader 即可。這就是所謂的高可用性。

關(guān)于Kafka，面試官一般喜歡考察哪些問題?

答案：

• 消息壓縮
• 消息解壓縮
• 分區(qū)策略
• 生產(chǎn)者如何實(shí)現(xiàn)冪等、事務(wù)
• Kafka Broker 是如何存儲(chǔ)數(shù)據(jù)?備份機(jī)制
• 為什么要引入消費(fèi)組?