阿裡三面:MQ 消息丟失、重覆、積壓問題,如何解決?

来源:https://www.cnblogs.com/javastack/archive/2023/09/13/17698757.html
-Advertisement-
Play Games

作者:美得讓人心動 來源:https://blog.csdn.net/gu131007416553/article/details/120934738 面試官在面試候選人時,如果發現候選人的簡歷中寫了在項目中使用了 MQ 技術(如 Kafka、RabbitMQ、RocketMQ),基本都會拋出一個問 ...


作者:美得讓人心動
來源:https://blog.csdn.net/gu131007416553/article/details/120934738

面試官在面試候選人時,如果發現候選人的簡歷中寫了在項目中使用了 MQ 技術(如 Kafka、RabbitMQ、RocketMQ),基本都會拋出一個問題:在使用 MQ 的時候,怎麼確保消息 100% 不丟失?

這個問題在實際工作中很常見,既能考察候選者對於 MQ 中間件技術的掌握程度,又能很好地區分候選人的能力水平。接下來,我們就從這個問題出發,探討你應該掌握的基礎知識和答題思路,以及延伸的面試考點。

案例背景

以京東系統為例,用戶在購買商品時,通常會選擇用京豆抵扣一部分的金額,在這個過程中,交易服務和京豆服務通過 MQ 消息隊列進行通信。在下單時,交易服務發送“扣減賬戶 X 100 個京豆”的消息給 MQ 消息隊列,而京豆服務則在消費端消費這條命令,實現真正的扣減操作。

那在這個過程中你會遇到什麼問題呢?

案例分析

要知道,在互聯網面試中,引入 MQ 消息中間件最直接的目的是:做系統解耦合流量控制,追其根源還是為瞭解決互聯網系統的高可用和高性能問題。

  • 系統解耦
    用 MQ 消息隊列,可以隔離系統上下游環境變化帶來的不穩定因素,比如京豆服務的系統需求無論如何變化,交易服務不用做任何改變,即使當京豆服務出現故障,主交易流程也可以將京豆服務降級,實現交易服務和京豆服務的解耦,做到了系統的高可用。
  • 流量控制:
    遇到秒殺等流量突增的場景,通過 MQ 還可以實現流量的“削峰填谷”的作用,可以根據下游的處理能力自動調節流量。

不過引入 MQ 雖然實現了系統解耦合流量控制,也會帶來其他問題。

引入 MQ 消息中間件實現系統解耦,會影響系統之間數據傳輸的一致性。 在分散式系統中,如果兩個節點之間存在數據同步,就會帶來數據一致性的問題。同理,在這一講你要解決的就是:消息生產端和消息消費端的消息數據一致性問題(也就是如何確保消息不丟失)。

而引入 MQ 消息中間件解決流量控制, 會使消費端處理能力不足從而導致消息積壓,這也是你要解決的問題。

所以你能發現,問題與問題之間往往是環環相扣的,面試官會藉機考察你解決問題思路的連貫性和知識體系的掌握程度。

那面對“在使用 MQ 消息隊列時,如何確保消息不丟失”這個問題時,你要怎麼回答呢?首先,你要分析其中有幾個考點,比如:

  • 如何知道有消息丟失?
  • 哪些環節可能丟消息?
  • 如何確保消息不丟失?

候選人在回答時,要先讓面試官知道你的分析思路,然後再提供解決方案:網路中的數據傳輸不可靠,想要解決如何不丟消息的問題,首先要知道哪些環節可能丟消息,以及我們如何知道消息是否丟失了,最後才是解決方案(而不是上來就直接說自己的解決方案)。就好比“架構設計”“架構”體現了架構師的思考過程,而“設計”才是最後的解決方案,兩者缺一不可。

案例解答

我們首先來看消息丟失的環節,一條消息從生產到消費完成這個過程,可以劃分三個階段,分別為消息生產階段,消息存儲階段和消息消費階段。

  • 消息生產階段: 從消息被生產出來,然後提交給 MQ 的過程中,只要能正常收到 MQ Broker 的 ack 確認響應,就表示發送成功,所以只要處理好返回值和異常,這個階段是不會出現消息丟失的。
  • 消息存儲階段: 這個階段一般會直接交給 MQ 消息中間件來保證,但是你要瞭解它的原理,比如 Broker 會做副本,保證一條消息至少同步兩個節點再返回 ack。
  • 消息消費階段: 消費端從 Broker 上拉取消息,只要消費端在收到消息後,不立即發送消費確認給 Broker,而是等到執行完業務邏輯後,再發送消費確認,也能保證消息的不丟失。

方案看似萬無一失,每個階段都能保證消息的不丟失,但在分散式系統中,故障不可避免,作為消息生產端,你並不能保證 MQ 是不是弄丟了你的消息,消費者是否消費了你的消息,所以,本著 Design for Failure 的設計原則,你還是需要一種機制,來 Check 消息是否丟失了。

緊接著,你還可以向面試官闡述怎麼進行消息檢測? 總體方案解決思路為:在消息生產端,給每個發出的消息都指定一個全局唯一 ID,或者附加一個連續遞增的版本號,然後在消費端做對應的版本校驗。

具體怎麼落地實現呢?你可以利用攔截器機制。 在生產端發送消息之前,通過攔截器將消息版本號註入消息中(版本號可以採用連續遞增的 ID 生成,也可以通過分散式全局唯一 ID生成)。然後在消費端收到消息後,再通過攔截器檢測版本號的連續性或消費狀態,這樣實現的好處是消息檢測的代碼不會侵入到業務代碼中,可以通過單獨的任務來定位丟失的消息,做進一步的排查。

這裡需要你註意:如果同時存在多個消息生產端和消息消費端,通過版本號遞增的方式就很難實現了,因為不能保證版本號的唯一性,此時只能通過全局唯一 ID 的方案來進行消息檢測,具體的實現原理和版本號遞增的方式一致。

現在,你已經知道了哪些環節(消息存儲階段、消息消費階段)可能會出問題,並有瞭如何檢測消息丟失的方案,然後就要給出解決防止消息丟失的設計方案。

回答完“如何確保消息不會丟失?” 之後,面試官通常會追問“怎麼解決消息被重覆消費的問題?

比如:在消息消費的過程中,如果出現失敗的情況,通過補償的機制發送方會執行重試,重試的過程就有可能產生重覆的消息,那麼如何解決這個問題?

這個問題其實可以換一種說法,就是如何解決消費端冪等性問題(冪等性,就是一條命令,任意多次執行所產生的影響均與一次執行的影響相同),只要消費端具備了冪等性,那麼重覆消費消息的問題也就解決了。

我們還是來看扣減京豆的例子,將賬戶 X 的金豆個數扣減 100 個,在這個例子中,我們可以通過改造業務邏輯,讓它具備冪等性。

最簡單的實現方案,就是在資料庫中建一張消息日誌表, 這個表有兩個欄位:消息 ID 和消息執行狀態。這樣,我們消費消息的邏輯可以變為:在消息日誌表中增加一條消息記錄,然後再根據消息記錄,非同步操作更新用戶京豆餘額。

因為我們每次都會在插入之前檢查是否消息已存在,所以就不會出現一條消息被執行多次的情況,這樣就實現了一個冪等的操作。當然,基於這個思路,不僅可以使用關係型資料庫,也可以通過 Redis 來代替資料庫實現唯一約束的方案。

在這裡我多說一句,想要解決“消息丟失”和“消息重覆消費”的問題,有一個前提條件就是要實現一個全局唯一 ID 生成的技術方案。這也是面試官喜歡考察的問題,你也要掌握。

在分散式系統中,全局唯一 ID 生成的實現方法有資料庫自增主鍵、UUID、Redis,Twitter-Snowflake 演算法,我總結了幾種方案的特點,你可以參考下。

我提醒你註意,無論哪種方法,如果你想同時滿足簡單、高可用和高性能,就要有取捨,所以你要站在實際的業務中,說明你的選型所考慮的平衡點是什麼。我個人在業務中比較傾向於選擇 Snowflake 演算法,在項目中也進行了一定的改造,主要是讓演算法中的 ID 生成規則更加符合業務特點,以及優化諸如時鐘回撥等問題。

當然,除了“怎麼解決消息被重覆消費的問題?”之外,面試官還會問到你“消息積壓”。 原因在於消息積壓反映的是性能問題,解決消息積壓問題,可以說明候選者有能力處理高併發場景下的消費能力問題。

你在解答這個問題時,依舊要傳遞給面試官一個這樣的思考過程: 如果出現積壓,那一定是性能問題,想要解決消息從生產到消費上的性能問題,就首先要知道哪些環節可能出現消息積壓,然後在考慮如何解決。

因為消息發送之後才會出現積壓的問題,所以和消息生產端沒有關係,又因為絕大部分的消息隊列單節點都能達到每秒鐘幾萬的處理能力,相對於業務邏輯來說,性能不會出現在中間件的消息存儲上面。毫無疑問,出問題的肯定是消息消費階段,那麼從消費端入手,如何回答呢?

如果是線上突發問題,要臨時擴容,增加消費端的數量,與此同時,降級一些非核心的業務。通過擴容和降級承擔流量,這是為了表明你對應急問題的處理能力。

其次,才是排查解決異常問題,如通過監控,日誌等手段分析是否消費端的業務邏輯代碼出現了問題,優化消費端的業務處理邏輯。

最後,如果是消費端的處理能力不足,可以通過水平擴容來提供消費端的併發處理能力,但這裡有一個考點需要特別註意, 那就是在擴容消費者的實例數的同時,必須同步擴容主題 Topic 的分區數量,確保消費者的實例數和分區數相等。如果消費者的實例數超過了分區數,由於分區是單線程消費,所以這樣的擴容就沒有效果。

比如在 Kafka 中,一個 Topic 可以配置多個 Partition(分區),數據會被寫入到多個分區中,但在消費的時候,Kafka 約定一個分區只能被一個消費者消費,Topic 的分區數量決定了消費的能力,所以,可以通過增加分區來提高消費者的處理能力。

總結

至此,我們講解了 MQ 消息隊列的熱門問題的解決方案,無論是初中級還是高級研發工程師,本篇文章的內容都是你需要掌握的,你都可以從這幾點出發,與面試官進行友好的交流。我來總結一下今天的重點內容。

  • 如何確保消息不會丟失? 你要知道一條消息從發送到消費的每個階段,是否存在丟消息,以及如何監控消息是否丟失,最後才是如何解決問題,方案可以基於“ MQ 的可靠消息投遞 ”的方式。
  • 如何保證消息不被重覆消費? 在進行消息補償的時候,一定會存在重覆消息的情況,那麼如何實現消費端的冪等性就這道題的考點。
  • 如何處理消息積壓問題? 這道題的考點就是如何通過 MQ 實現真正的高性能,回答的思路是,本著解決線上異常為最高優先順序,然後通過監控和日誌進行排查並優化業務邏輯,最後是擴容消費端和分片的數量。

在回答問題的時候,你需要特別註意的是,讓面試官瞭解到你的思維過程,這種解決問題的能力是面試官更為看中的,比你直接回答一道面試題更有價值。

另外,如果你應聘的部門是基礎架構部,那麼除了要掌握本講中的常見問題的主線知識以外,還要掌握消息中間件的其他知識體系,如:

  • 如何選型消息中間件?
  • 消息中間件中的隊列模型與發佈訂閱模型的區別?
  • 為什麼消息隊列能實現高吞吐?
  • 序列化、傳輸協議,以及記憶體管理等問題
  • … >

好了,今天就分享這麼多,有收穫的話,給個三連唄!

近期熱文推薦:

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆!Java 協程要來了。。。

3.Spring Boot 2.x 教程,太全了!

4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這才是優雅的方式!!

5.《Java開發手冊(嵩山版)》最新發佈,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 通過這個解釋,我們將瞭解當Python程式顯示類似NameError: name '' is not defined的錯誤時,即使該函數存在於腳本中,也會出現這種情況。 我們還學習了當我們使用拼寫錯誤的變數或沒有導入的內置函數時會發生什麼,以及如何在Python中避免這些錯誤。 避免在Python聲 ...
  • 本文將使用實際的例子來解釋Python的urlparse() 函數來解析和提取URL中的功能變數名稱。我們還將討論如何提高我們解析 URL 的能力和使用它們的不同組件。 用urlparse() 從 URL 中提取功能變數名稱 urlparse() 方法是Python的urllib 模塊的一部分,當你需要將URL拆分 ...
  • Java實現常見查找演算法 查找是在大量的信息中尋找一個特定的信息元素,在電腦應用中,查找是常用的基本運算,例如編譯程式中符號表的查找。 線性查找 線性查找(Linear Search)是一種簡單的查找演算法,用於在數據集中逐一比較每個元素,直到找到目標元素或搜索完整個數據集。它適用於任何類型的數據集 ...
  • Matplotlib 提供了大量配置參數,這些參數可以但不限於讓我們從整體上調整通過 Matplotlib 繪製的圖形樣式,這裡面的參數還有很多是功能性的,和其他工具結合時需要用的配置。 通過plt.rcParams,可以查看所有的配置信息: import matplotlib.pyplot as ...
  • 大家好,我是TJ 今天給大家推薦一個開源協作式數字白板:tldraw。 tldraw的編輯器、用戶界面和其他底層庫都是開源的,你可以在它的開源倉庫中找到它們。它們也在NPM上分發,提供開發者使用。您可以使用tlDraw為您的產品創建一個臨時白板,或者將其作為構建自己應用的工具來使用。 線上體驗 tl ...
  • 基於java學生考勤管理系統設計與實現,可適用於學生考勤系統,校園考勤,大學考勤管理,企業考勤系統,公司考勤系統,學校考勤系統。 ...
  • 隨著JDK19的發佈,虛擬線程也逐漸被大家瞭解和使用,然而,主流java框架是否支持虛擬線程這一特性呢?咱們應用開發者如何通過框架使用虛擬線程特性?經過精心準備,欣宸原創在第一時間為您帶來詳細的實戰系列,與您共同學習 ...
  • 大家好,又見面了。 在此前我的文章中,曾分2篇詳細探討了下JAVA中Stream流的相關操作,2篇文章收穫了累計 10w+閱讀、2k+點贊以及 5k+收藏的記錄。能夠得到眾多小伙伴的認可,是技術分享過程中最開心的事情。 吃透JAVA的Stream流操作,多年實踐總結 講透JAVA Stream的co ...
一周排行
    -Advertisement-
    Play Games
  • 下麵是一個標準的IDistributedCache用例: public class SomeService(IDistributedCache cache) { public async Task<SomeInformation> GetSomeInformationAsync (string na ...
  • 這個庫提供了在啟動期間實例化已註冊的單例,而不是在首次使用它時實例化。 單例通常在首次使用時創建,這可能會導致響應傳入請求的延遲高於平時。在註冊時創建實例有助於防止第一次Request請求的SLA 以往我們要在註冊的時候實例單例可能會這樣寫: //註冊: services.AddSingleton< ...
  • 最近公司的很多項目都要改單點登錄了,不過大部分都還沒敲定,目前立刻要做的就只有一個比較老的項目 先改一個試試手,主要目標就是最短最快實現功能 首先因為要保留原登錄方式,所以頁面上的改動就是在原來登錄頁面下加一個SSO登錄入口 用超鏈接寫的入口,頁面改造後如下圖: 其中超鏈接的 href="Staff ...
  • Like運算符很好用,特別是它所提供的其中*、?這兩種通配符,在Windows文件系統和各類項目中運用非常廣泛。 但Like運算符僅在VB中支持,在C#中,如何實現呢? 以下是關於LikeString的四種實現方式,其中第四種為Regex正則表達式實現,且在.NET Standard 2.0及以上平... ...
  • 一:背景 1. 講故事 前些天有位朋友找到我,說他們的程式記憶體會偶發性暴漲,自己分析了下是非托管記憶體問題,讓我幫忙看下怎麼回事?哈哈,看到這個dump我還是非常有興趣的,居然還有這種游戲幣自助機類型的程式,下次去大玩家看看他們出幣的機器後端是不是C#寫的?由於dump是linux上的程式,剛好win ...
  • 前言 大家好,我是老馬。很高興遇到你。 我們為 java 開發者實現了 java 版本的 nginx https://github.com/houbb/nginx4j 如果你想知道 servlet 如何處理的,可以參考我的另一個項目: 手寫從零實現簡易版 tomcat minicat 手寫 ngin ...
  • 上一次的介紹,主要圍繞如何統一去捕獲異常,以及為每一種異常添加自己的Mapper實現,並且我們知道,當在ExceptionMapper中返回非200的Response,不支持application/json的響應類型,而是寫死的text/plain類型。 Filter為二方包異常手動捕獲 參考:ht ...
  • 大家好,我是R哥。 今天分享一個爽飛了的面試輔導 case: 這個杭州兄弟空窗期 1 個月+,面試了 6 家公司 0 Offer,不知道問題出在哪,難道是杭州的 IT 崩盤了麽? 報名面試輔導後,經過一個多月的輔導打磨,現在成功入職某上市公司,漲薪 30%+,955 工作制,不咋加班,還不捲。 其他 ...
  • 引入依賴 <!--Freemarker wls--> <dependency> <groupId>org.freemarker</groupId> <artifactId>freemarker</artifactId> <version>2.3.30</version> </dependency> ...
  • 你應如何運行程式 互動式命令模式 開始一個互動式會話 一般是在操作系統命令行下輸入python,且不帶任何參數 系統路徑 如果沒有設置系統的PATH環境變數來包括Python的安裝路徑,可能需要機器上Python可執行文件的完整路徑來代替python 運行的位置:代碼位置 不要輸入的內容:提示符和註 ...