[[408564]]

本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。

大家好，我是煎魚。

前段時間我們分享了《漫談 MQ》的第一期《要消息隊列(MQ)有什么用?》，感覺打開了一個新的世界。

但很快就有小伙伴意識到了不妙，既然 MQ 承接了多個系統，那豈不是該有的問題，他都有，又或是更甚。如下：

今天我們就進一步講講，設計 MQ 時很有可能會遇到的幾個大難點，在業內又配套用了什么解決方案去處理。

幾個難點

從結論上來看，設計 MQ 這一個存在。會至少引發三大難點。堪稱互聯網經典的，也是面試官們最愛問的：

• 高可用：代表系統的可用性程度，高可用性通常通過提高系統的容錯能力來實現，從而減少系統宕機時間。
• 高并發：代表通過設計保證系統能夠同時并行處理很多請求，在同一個時間點，有很多用戶同時訪問同一系統、API、URL。
• 高可靠：代表能夠滿足預計條件的一個系統或組件(例如：備份、故障處理、數據存儲以及訪問)，比較經典的是 4 個9 等標準。

高可用

像前面評論區留言的兄弟截圖表述的一樣。

雖然請求不直接找系統 A、B、C、D 了。但是請求都實打實的通過異步的方式打到了 MQ 上，就可以不斷往 MQ 塞，變成了多個系統都在請求 MQ，可以認為壓力比單系統同步調用大了不止一倍。

同時 MQ 還要去做消費關系的維護，存儲既有和新增的大量消息。是一個既要也要還要的典型場景。

這樣一來，新的一輪問題就出現了。就是要保證 MQ 的高可用，否則他輕輕松松就會被壓到宕機，或是負載過高，出現一些匪夷所思的延遲。

如何保證 MQ 的高可用，是一個大問題。

高并發

在高并發上的訴求上，其實是和高可用的場景是一樣的。既然各業務系統都是異步的了，自然他也就不會像同步阻塞一樣 “等” 你。

像是我有一個朋友，他們喜歡批量清洗多租戶的數據。業務程序也不怎么節制，幾十、幾百、上千萬數據，利用 Go 語言寫的，抄起 for-loop+go func 就是一把梭。刷刷刷一下子就就給打進 MQ 里。

再多來幾個業務系統這么干，這 MQ 并發就比較高了，單單維護就是頭疼。很有可能事故背著背著，年底就 3.25 了。因為 MQ，在業務中的依賴非常重，是標準的核心基礎設施。

如何保證 MQ 能夠承受高并發，是一個大問題。

高可靠

對 MQ 來講，高可靠性的訴求，又分為好幾個角度去理解。如下：

• 消息要靠譜：“我” 發的消息要能夠可靠的到達 MQ，MQ 要能夠正確的讓消費者能夠接收到推送或拉取。
• 存儲要靠譜：“我” 發的消息，還在 MQ 上時要存儲好，不能發到 MQ 上就因為大量數據，丟了。又或是查詢很慢。
• 處理要靠譜：發了消息，可能會出現異常。發了消息，可能網絡抖動，沒有接收到。

上述我們列了三點 “要靠譜” 的內容。實質上，對于 MQ 來講，其每一塊領域都要保證其可靠性，否則查起問題來，真的是會非常崩潰。

甚至更往上，還會對 “高性能” 會有要求，不過這一塊我們就不進一步展開了。

解決方案

核心流程

在清楚了設計 MQ 會遇到的三大難點后。我們需要先了解一下現代 MQ 的基礎應用架構會是怎么樣的。

MQ 包含如下三類角色：

• 生產者(Producer)：負責生產消息。
• 消費者(Consumer)：負責消費消息。
• 服務端(Broker)：負責存儲和處理消息，是 MQ 的核心部分。由隊列(Queue)延伸而來，因為功能已經不僅僅局限于隊列屬性了。

其核心流程如下：

核心流程

• 生產者(Producer)發送消息到達服務端(Broker)，服務端進行消息存儲，核心邏輯處理等。
• 再根據先前注冊消費的關系(例如：訂閱)，進行消息的推送或被拉取。也就是消費消息了。
• 在完成消費消息后再返回確認(ACK)給服務端。若出現一定時間內未收到 ACK，則會觸發服務端的重試機制。
• 服務端確定消息處理完畢，刪除消息和進行記錄。

對三高下手

設計高可用

在高可用上，主要要針對服務端(Broker)來做。目前常見的是保證服務端可以進行水平擴展，能夠做跨集群的部署。

因此相應上得配套做服務的注冊和發現機制，負載均衡(確保服務端壓力均衡)。以此來構成 MQ 高可用的基本維持。

設計高并發

在高并發上，服務端必然包含隊列(Queue)，會起到緩沖的作用。但仍然可能會出現單點流量過大。

因此通常會結合像是 RocketMQ 的 Topic，Kafka 的 Partition 等做隊列劃分，起到分而治之的作用。

設計高可靠

在高可靠上，主要是針對消息發送、存儲消息、處理消息這三塊進行展開。

消息發送上，會結合 SDK 和服務端兩者，發送和消費消息的確認(ACK)機制、重試機制等來實現消息的可靠性。

存儲消息上，常見分為：分布式緩存、分布式文件系統、數據庫方案等。目前主流的話，會采取落盤的方式，也就是將消息主體追加寫入到日志文件，再配合索引文件來做快速的消息查找。

和 MySQL 數據庫的存儲模式是有一定的神似之處。

總結

在今天這篇文章中，我們面向設計 MQ 中常見的 3 大難點(其實還有更多，以后再介紹...)進行了逐一介紹和說明。同時也針對業內常見的解決方案進行了剖析。

在我們了解了這些細節后，在真正應用 MQ 時，就不會感到那么的無奈。因為常常你所遇到的，消息丟失，又或是消息重試導致裂變所導致宕機。

 

往往都來自于你所忽略的這些設計細節之中。即使對到用戶端上只是幾個簡單的配置，你也應當理解這些知識 ：)