位元組跳動面試官：為什么要用訊息佇列？你專案中是怎么用的？

Part1是什么？為什么？

1、什么是訊息佇列

說到Java中的佇列應該都不會陌生，其具有通過先進先出，或者雙端進出的方式進行資料管理；通過阻塞以達到自動平衡負載的功能，

訊息佇列之所以以佇列命名，起初也是因為其功能和操作，和java的本地佇列有相似之處，所以，我們可以簡單的認為訊息佇列就是為了滿足分布式下各服務之間的資料傳輸、管理和消費的一種中間服務，

2、為什么要使用訊息佇列

問：你們的系統中為什么要引入訊息佇列？

我們總歸需要知曉訊息佇列的使用價值，以及自己的業務場景下的實際痛點才能回答為什么要用訊息佇列這個問題，才能回答系統引入訊息佇列的價值所在，

系統間解耦

圖片廣告檢索系統，需要感知廣告貼的資訊變動來更新自己的索引，但實際上檢索系統和投放、物料、資產等系統間沒有必要依靠介面對感知行為進行強關聯，且介面的方式在維護和系統的壓力方面不友好，那么，訊息佇列的作用就顯的很重要了，各系統發布各自的訊息，誰需要誰訂閱，達到目的同時不會增加額外的系統呼叫壓力，（注：builder的介面呼叫是為了獲取最新的資訊，此處可以通過壓縮等方式進行優化）

因此，當系統間無實時資料互動要求，但還需要其業務資訊時，可以用訊息佇列來達到系統間解耦的作用，只要發布方定義好訊息佇列格式，消費方的任何操作均可和發布方無關，減少了不必要的聯調和發布沖突等影響，

服務異步化
最典型的一個例子，就是支付場景下的結果通知功能，

我們知道，一般情況下不管是app push 還是短信通知，都是比較耗時的操作，所以，沒有必要因為這些非核心功能的耗時操作而影響了支付的核心操作，只要我們在支付操作完成之后，將支付結果發到短信中心指定的訊息topic下，短信中心自然會接收到此訊息并保證通知給用戶，

因此使用訊息佇列，讓非核心的操作異步化，提高整個業務鏈路的高效和穩定，是很有效的，

削峰填谷
這個功能使我們本篇關注的重點，面對特殊場景如秒殺、春晚紅包等萬億級流量的脈沖式壓力下，一種保護我們系統的服務免于崩潰的有效手段就是訊息佇列，

通過訊息中心高性能的存盤和處理能力，將超過系統處理能力的多余流量暫時存盤起來，并在系統處理能力內平緩釋放出來，達到削峰的效果，

比如我們的廣告計費系統，面對上萬并發的商業貼檢索量，數千并發的點擊操作，實時介面的方式一定是不合適的，畢竟廣告行為和支付行為不一樣，支付失敗用戶還可以重試，但用戶的商業貼點擊行為是不可回放的，本次流量過去就過去了，因此，需要利用訊息佇列將扣費請求快取下來，來保證計費系統的穩定，

其他
還如廣播、事務型、最終一致性等特性，也是訊息佇列經常用到的功能，

3、訊息佇列會存在哪些問題

業務上增加回應延遲
前面提到，訊息佇列使得業務非核心流程異步化，可以提高整個業務操作的時效性和流暢度，提升用戶操作體驗，但，也是因為資料進入佇列的原因，不可避免的會耽擱消費速度，導致業務生效不及時，

比如，之前遇到的商品推薦，產品要求推薦串列中不能出現滿減秒殺的商品，以消除特殊商品對推薦效果產生影響，除了秒殺，我們還需要感知商品的上下架、黑名單、庫存等等，因次，用redis中的bit多個偏移量來維護一個商品的多個狀態，然后接收促銷組的訊息來變更推薦快取集群中的商品狀態，但由于訊息的延遲，就有可能導致商品狀態變更不及時的情況發生，不過只要權衡之下業務和技術上是可接受的就OK了，

架構上引入不穩定因素
訊息佇列的引入，相當于在原有的分布式服務鏈路中新增了一個系統，系統復雜度也隨之變大了，同時，訊息佇列的作用要求其具有高性能和高可用，

所以，面對怎樣部署高可用穩定集群、訊息發送不成功怎么重試、broker資料同步策略怎么設定、broker例外導致訊息重發怎么冪等、消費不成功怎么重試等等問題，需要中間件團隊和業務系統一起努力應對，

Part2怎么樣？

4、支撐七年雙11零故障的RocketMQ
2020 年雙十一交易峰值達到 58.3W 筆/秒，RocketMQ為了阿里的交易生態有很多深度定制，這里我們只介紹其中針對高可用的優化，

個人理解，push消費模式只適合于消費速度遠大于生產速度的場景，如果是大流量并發場景，基本還是以Pull消費為主，

而pull前broker和client間會進行負載均衡建立連接，那么，一旦Client被Hang住,(沒有宕就不會rebalance，即時宕機也是默認20s才會rebalance)，就會讓broker與該client關聯的佇列訊息無法及時被消費，導致積壓，怎么辦：POP，新的消費模式

POP 消費中并不需要rebalance去分配消費佇列，取而代之的是請求所有的 broker 獲取訊息進行消費，broker 內部會把自身的三個佇列的訊息根據一定的演算法分配給等待的 POPClient，即使 PopClient 2 出現 hang，但內部佇列的訊息也會讓 Pop Client1 和 Pop Client2 進行消費，這樣避免了消費堆積，[1]

5、快手萬億級kafka集群的平滑擴容[2]
要實作平滑，則需要讓producer無感的實作partition遷移，

大致原理是將待遷移partition的資料和新的partition資料進行同步并持續一段時間，直到消費者全部趕上同步的開始節點，然后再變更路由，洗掉原partition，完成遷移，


相同的資料同步思路，在facebook的分布式佇列災備方案上也有應用，

6、快手/美團對kafka快取污染的優化

kafka的高性能，來源于順序檔案讀寫和作業系統快取pagecache的支持，在單partition，單consumer的場景下，kafka表現的非常優秀，但是，如果同一機器上，存在不同的partition,甚至，消費模式有實時和延遲消費的混合場景，將會出現PageCache資源競爭，導致快取污染，影響broker的服務的處理效率，

美團應對實時/延遲消費快取污染
將資料按照時間維度分布在不同的設備中，近實時部分的資料快取在 SSD 中，這樣當出現 PageCache 競爭時，實時消費作業從 SSD 中讀取資料，保證實時作業不會受到延遲消費作業影響

當消費請求到達 Broker 時，Broker 直接根據其維護的訊息偏移量和設備的關系從對應的設備中獲取資料并回傳，并且在讀請求中并不會將 HDD 中讀取的資料回刷到 SSD，防止出現快取污染，同時訪問路徑明確，不會由于 Cache Miss 而產生的額外訪問開銷，

快手應對follower資料同步引起的快取污染

broker 中引入了兩個物件：一個是 block cache；另一個是 flush queue，

Producer 的寫入請求在 broker 端首先會被以原 message 的形式寫入 flush queue 中，之后再將資料寫入到 block cache 的一個 block 中，之后整個請求就結束了，在 flush queue 中的資料會由其他執行緒異步地寫入到磁盤中（會經歷 page cache 程序），保證queue不受follower的影響

consumer 首先會從 block cache 中檢索資料，如果命中，則直接回傳，否則，則從磁盤讀取資料，這樣的讀取模式保障了 consumer 的 cache miss 讀并不會填充 block cache，從而避免了產生污染，

總結
我們可以看出，解決快取污染的基本出發點，還是要拆解不同消費速度的任務、或不同的資料生產來源，分而治之的思路避免相互間快取的影響，

7、CMQ在紅包支付場景下的應用

紅包操作的背后流程簡化為：從 A 帳號中把余額讀出來，然后做減法操作，再把結果寫回 A 帳號中；然后拆紅包對 B 帳號做加法操作，把結果寫到 B 帳號中，

而由于賬務系統能承載的壓力有限(和賬務相關的系統一般都會由于鎖、事務等原因影響處理效率)，可能導致入賬失敗，如果按實時業務邏輯，則需要對拆紅包進行實時回滾(回滾需要對A的賬戶再進行一次加法)，而引入CMQ后，業務鏈路變成將失敗的請求寫入CMQ，由CMQ的高可用來保證資料一致，直到賬務系統最終入賬成功，簡化了賬務系統由于系統壓力而導致的入賬失敗而導致紅包賬務回滾帶來的額外系統操作，

Part3總結

本篇從訊息佇列的作用出發，從阿里雙11、快手、美團、微信紅包等案例，就訊息佇列本身的優化方案和業務對訊息佇列的高效利用，闡述了訊息佇列在高并發的優化場景下的作用，如有問題，歡迎留言討論，相互學習！

最后

小伙伴們，幫忙一鍵三連呀

題外話，我在一線互聯網企業作業十余年里，指導過不少同行后輩，幫助很多人得到了學習和成長，

我意識到有很多經驗和知識值得分享給大家，也可以通過我們的能力和經驗解答大家在Java學習中的很多困惑，所以在作業繁忙的情況下還是堅持各種整理和分享，但苦于知識傳播途徑有限，很多程式員朋友無法獲得正確的資料得到學習提升

故此將并將重要的Java進階資料包括并發編程、JVM調優、SSM、設計模式、spring等知識技術、阿里面試題精編匯總、常見原始碼分析等錄播視頻免費分享出來，需要領取的麻煩點這里自行下載或者是添加QQ1404119194，備注csdn

Java進階視頻資料

Java面試題精編匯總

JAVA核心知識點整理

獲取方式： 只需你一鍵三連后，掃描👇二維碼自行免費下載或者添加QQ1404119194，備注csdn