消息中間件篇

RabbitMQ

如何保證消息不丟失

面試官： RabbitMQ如何保證消息不丟失

候選人：

嗯！我們當時MYSQL和Redis的數(shù)據(jù)雙寫一致性就是采用RabbitMQ實現(xiàn)同步的，這里面就要求了消息的高可用性，我們要保證消息的不丟失。主要從三個層面考慮

第一個是開啟生產(chǎn)者確認機制，確保生產(chǎn)者的消息能到達隊列，如果報錯可以先記錄到日志中，再去修復(fù)數(shù)據(jù)

第二個是開啟持久化功能，確保消息未消費前在隊列中不會丟失，其中的交換機、隊列和消息都要做持久化

第三個是開啟消費者確認機制為auto，由spring確認消息處理成功后完成ack，當然也需要設(shè)置一定的重試次數(shù)，我們當時設(shè)置了3次，如果重試3次還沒有收到消息，就將失敗后的消息投遞到異常交換機，交由人工處理

消息的重復(fù)消費問題如何解決的

面試官： RabbitMQ消息的重復(fù)消費問題如何解決的

候選人：

嗯，這個我們還真遇到過，是這樣的，我們當時消費者設(shè)置了自動確認機制，當服務(wù)還沒來得及給MQ確認的時候，服務(wù)宕機了，導(dǎo)致服務(wù)重啟之后，又消費了一次消息。這樣就重復(fù)消費了

因為我們當時處理的支付（訂單 | 業(yè)務(wù)唯一標識），它有一個業(yè)務(wù)的唯一標識，我們再處理消息時，先到數(shù)據(jù)庫查詢一下，這個數(shù)據(jù)是否存在，如果不存在，說明沒有處理過，這個時候就可以正常處理這個消息了。如果已經(jīng)存在這個數(shù)據(jù)了，就說明消息重復(fù)消費了，我們就不需要再消費了

面試官： 那你還知道其他的解決方案嗎？

候選人：

嗯，我想想~

其實這個就是典型的冪等的問題，比如，redis分布式鎖、數(shù)據(jù)庫的鎖都是可以的

死信交換機

面試官： RabbitMQ中死信交換機？（RabbitMQ延遲隊列有了解過嘛）

候選人：

嗯！了解過！

我們當時的xx項目有一個xx業(yè)務(wù)，需要用到延遲隊列，其中就是使用RabbitMQ來實現(xiàn)的。

延遲隊列就是用到了死信交換機和TTL（消息存活時間）實現(xiàn)的。

如果消息超時為消費就會變成死信，在RabbitMQ中如果消息成為死信，隊列可以綁定一個死信交換機，在死信交換機上可以綁定其他隊列，在我們發(fā)消息的時候可以按照需求指定TTL的時間，這樣就實現(xiàn)了延遲隊列的功能了。

我記得RabbitMQ還有一種方式可以實現(xiàn)延遲隊列，在RabbitMQ中安裝一個死信插件，這樣更方便一些，我們只需在聲明交換機的時候，指定這個就是死信交換機，然后在發(fā)消息的時候直接指定超時時間就行了，相對于死信交換機+TTL省略了一些步驟

消息堆積怎么解決

面試官： 如果有100萬消息堆積在MQ，如何解決？

候選人：

我在實際的開發(fā)中，沒遇到過這種問題，不過，如果發(fā)生了堆積的問題，解決方案也有很多的

第一：提高消費者的消費能力，可以使用多線程消費任務(wù)

第二：增加更多消費者，提高消費速度，使用工作隊列模式，設(shè)置多個消費者消費同一個隊列中的消息

第三：擴大隊列容積，提高堆積上限

可以使用RabbitMQ惰性隊列，惰性隊列的好處主要是

①接收到消息后直接存入磁盤而非內(nèi)存

②消費者要消費消息時才會從磁盤中讀取并加載到內(nèi)存

③支持百萬條的消息存儲

高可用機制

面試官： RabbitMQ的高可用機制有了解過嘛

候選人：

嗯，熟悉的~

我們當時項目在生產(chǎn)環(huán)境下，使用的集群，當時搭建的是鏡像集群，使用了3臺機器。

鏡像隊列結(jié)構(gòu)是一主多從，所有操作都是主節(jié)點完成，然后同步給鏡像節(jié)點，如果主節(jié)點宕機后，鏡像節(jié)點會替代成新的節(jié)點，不過在主從同步完成前，主節(jié)點就已宕機，可能出現(xiàn)數(shù)據(jù)丟失

面試官： 那出現(xiàn)丟數(shù)據(jù)怎么解決呢？

候選人：

我們可以采用仲裁隊列，與鏡像隊列一樣，都是主從模式，支持主從數(shù)據(jù)同步，主從同步基于Raft協(xié)議，強一致。

并且使用起來也非常簡單，不需要額外的配置，在聲明隊列的時候只要指定這個是仲裁隊列即可

Kafka

如何保證消息不丟失

面試官： Kafka是如何保證消息不丟失

候選人：

嗯，這個保證機制很多，在發(fā)送消息到消費者接收消息，在每個階段都有可能會丟失消息，所以我們解決的話也是從多個方面考慮

第一個是生產(chǎn)者發(fā)送消息的時候，可以使用異步回調(diào)發(fā)送，如果發(fā)送消息失敗，我們可以通過回調(diào)獲取失敗后的消息信息，可以考慮重試或記錄日志，后邊再做補償都是可以的。同時在生產(chǎn)者這邊還可以設(shè)置消息重試，有的時候是由于網(wǎng)絡(luò)抖動的原因?qū)е掳l(fā)送不成功，就可以使用重試機制來解決

第二個在broker中消息有可能會丟失，我們可以通過kafka的復(fù)制機制來確保消息不丟失，在生產(chǎn)者發(fā)送消息的時候，可以設(shè)置一個acks，就是確認機制。我們可以設(shè)置參數(shù)為all，這樣的話，當生產(chǎn)者發(fā)送消息到了分區(qū)之后，不僅僅只在leader分區(qū)保存確認，在follwer區(qū)分也會保存確認，只有當所有的副本都保存確認以后才算是成功發(fā)送了消息，所以，這樣設(shè)置就很大程度保證了消息不會在broker丟失

第三個是有可能在消費者端丟失消息，kafka消費消息都是按照offset進行標記消費的，消費者默認是自動按期提交已經(jīng)消費的偏移量，默認是每隔5s提交一次，如果出現(xiàn)重平衡的情況，可能會重復(fù)消費或丟失數(shù)據(jù)。我們一般都會禁用掉自動提交偏移量，改為手動提交，當消費成功以后再報告給broker消費的位置，這樣就可以避免消息丟失和重復(fù)消費了

面試官： Kafka中消息的重復(fù)消費問題如何解決的

候選人：

kafka消費消息都是按照offset進行標記消費的，消費者默認是自動按期提交已經(jīng)消費的偏移量，默認是每隔5s提交一次，當消費成功以后再報告給broker消費的位置，這樣就可以避免消息丟失和重復(fù)消費了

為了消息的冪等，我們也可以設(shè)置唯一主鍵來進行區(qū)分，或者是加鎖，數(shù)據(jù)庫的鎖，或者是redis分布式鎖，都能解決冪等的問題

如何保證消息的順序性

面試官： Kafka是如何保證消費的順序性

候選人：

kafka默認存儲和消費消息，是不能保證順序性的，因為一個topic數(shù)據(jù)可能存儲在不同的分區(qū)中，每個分區(qū)都有一個按照順序的存儲的偏移量，如果消費者關(guān)聯(lián)了多個分區(qū)不能保證順序性

如果有這樣的需求的話，我們是可以解決的，把消息都存儲在同一個分區(qū)下就行了，有兩種方式都可以進行設(shè)置，第一個是發(fā)送消息時指定分區(qū)號，第二個是發(fā)送消息時按照相同的業(yè)務(wù)設(shè)置相同的key，因為默認情況下分區(qū)也是通過key的hashcode值來選擇分區(qū)的，hash值如果一樣的話，分區(qū)肯定也是一樣的

高可用機制

面試官： Kafka的高可用機制有了解過嘛

候選人：

嗯，主要是有兩個層面，第一個是集群，第二個是提供了復(fù)制機制

Kafka集群指的是由多個broker實例組成，即使某一臺宕機，也不耽誤其他broker繼續(xù)對外提供服務(wù)

復(fù)制機制是可以保證kafka的高可用的，一個topic有多個分區(qū)，每個分區(qū)有多個副本，有一個leader，其余的是follower，副本存儲在不同的broker中；所有的分區(qū)副本的內(nèi)容都是相同的，如果leader發(fā)生故障時，會自動將其中一個follower提升為leader，保證了系統(tǒng)的容錯性、高可用性

面試官： 解釋一下復(fù)制機制中的ISR

候選人：

ISR的意思是in-sync replica，就是需要同步復(fù)制保存的follower

其中分區(qū)副本有很多的follower，分為了兩類，一個是ISR，與leader副本同步保存數(shù)據(jù)，另外一個普通的副本，是異步同步數(shù)據(jù)，當leader掛掉之后，會優(yōu)先從ISR副本列表中選取一個作為leader，因為ISR是同步保存數(shù)據(jù)，數(shù)據(jù)更加的完整一些，所以優(yōu)先選擇ISR副本列表

數(shù)據(jù)清理機制

面試官： Kafka的數(shù)據(jù)清理機制了解過嘛

候選人：

嗯，了解過~~

Kafka中topic的數(shù)據(jù)存儲在分區(qū)上，分區(qū)如果文件過大會分段存儲segment

每個分段都在磁盤上以索引(xxxx.index)和日志文件(xxxx.log)的形式存儲，這樣分段的好處是，第一能夠減少單個文件內(nèi)容的大小，查找數(shù)據(jù)方便，第二方便kafka進行日志清理。

在kafka中提供了兩個日志的清理策略：

第一、根據(jù)消息的保留時間，當消息保存的時間超過了指定的時間，就會觸發(fā)清理，默認是168消失（7天）

第二、根據(jù)topic存儲的數(shù)據(jù)大小，當topic所占的日志文件大小大于一定的閾值，則開始刪除最久的消息。這個默認是關(guān)閉的

這兩個策略都可以通過kafka的borker中的配置文件進行設(shè)置

高性能的設(shè)計

面試官： Kafka中實現(xiàn)高性能的設(shè)計有了解過嘛

候選人：

Kafka 高性能，是多方面協(xié)同的結(jié)果，包括宏觀架構(gòu)、分布式存儲、ISR數(shù)據(jù)同步、以及高效的利用磁盤、操作系統(tǒng)特性等。主要體現(xiàn)有這么幾點：

消息分區(qū)：不受單臺服務(wù)器的限制，可以不受限的處理更多的數(shù)據(jù)

順序讀寫：磁盤順序讀寫，提升讀寫效率

頁緩存：把磁盤中的數(shù)據(jù)緩存到內(nèi)存中，把對磁盤的訪問變?yōu)閷?nèi)存的訪問

零拷貝：減少上下文切換及數(shù)據(jù)拷貝

消息壓縮：減少磁盤IO和網(wǎng)絡(luò)IO

分批發(fā)送：將消息打包批量發(fā)送，減少網(wǎng)絡(luò)開銷