當前位置: 妍妍網 > 碼農

阿裏三面:MQ 訊息遺失、重復、積壓問題,如何解決?

2024-01-28碼農

來自: 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 實作真正的高效能,回答的思路是,本著解決線上異常為最高優先級,然後透過監控和日誌進行排查並最佳化業務邏輯,最後是擴容消費端和分片的數量。

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

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

  • 如何選型訊息中介軟體?

  • 訊息中介軟體中的佇列模型與釋出訂閱模型的區別?

  • 為什麽訊息佇列能實作高吞吐?

  • 序列化、傳輸協定,以及記憶體管理等問題

  • … >


  • <END>