為什么要使用消息隊列

本篇內容介紹了“為什么要使用消息隊列”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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緩存污染的優化[3]

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，從而避免了產生污染。

總結

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

7CMQ在紅包支付場景下的應用[4]

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

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

“為什么要使用消息隊列”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！