消息隊列設計精要

消息隊列已經逐漸成爲企業IT系統內部通訊的核心手段。它具備低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成爲異步RPC的主要手段之一。

當今市面上有不少主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，煊赫一時的Kafka，阿里巴巴自主開發的Notify、MetaQ、RocketMQ等。

本文不會一一介紹這些消息隊列的全部特性，而是探討一下自主開發設計一個消息隊列時，你須要思考和設計的重要方面。過程當中咱們會參考這些成熟消息隊列的不少重要思想。

本文首先會闡述何時你須要一個消息隊列，而後以Push模型爲主，從零開始分析設計一個消息隊列時須要考慮到的問題，如RPC、高可用、順序和重複消息、可靠投遞、消費關係解析等。

也會分析以Kafka爲表明的pull模型所具有的優勢。最後是一些高級主題，如用批量/異步提升性能、pull模型的系統設計理念、存儲子系統的設計、流量控制的設計、公平調度的實現等。其中最後四個方面會放在下篇講解。

什麼時候須要消息隊列

當你須要使用消息隊列時，首先須要考慮它的必要性。可使用mq的場景有不少，最經常使用的幾種，是作業務解耦/最終一致性/廣播/錯峯流控等。反之，若是須要強一致性，關注業務邏輯的處理結果，則RPC顯得更爲合適。

解耦

解耦是消息隊列要解決的最本質問題。所謂解耦，簡單點講就是一個事務，只關心核心的流程。而須要依賴其餘系統但不那麼重要的事情，有通知便可，無需等待結果。換句話說，基於消息的模型，關心的是「通知」，而非「處理」。

好比在美團旅遊，咱們有一個產品中心，產品中心上游對接的是主站、移動後臺、旅遊供應鏈等各個數據源；下游對接的是篩選系統、API系統等展現系統。當上遊的數據發生變動的時候，若是不使用消息系統，勢必要調用咱們的接口來更新數據，就特別依賴產品中心接口的穩定性和處理能力。但其實，做爲旅遊的產品中心，也許只有對於旅遊自建供應鏈，產品中心更新成功纔是他們關心的事情。而對於團購等外部系統，產品中心更新成功也好、失敗也罷，並非他們的職責所在。他們只須要保證在信息變動的時候通知到咱們就行了。

而咱們的下游，可能有更新索引、刷新緩存等一系列需求。對於產品中心來講，這也不是咱們的職責所在。說白了，若是他們定時來拉取數據，也能保證數據的更新，只是實時性沒有那麼強。但使用接口方式去更新他們的數據，顯然對於產品中心來講太過於「重量級」了，只須要發佈一個產品ID變動的通知，由下游系統來處理，可能更爲合理。

再舉一個例子，對於咱們的訂單系統，訂單最終支付成功以後可能須要給用戶發送短信積分什麼的，但其實這已經不是咱們系統的核心流程了。若是外部系統速度偏慢（好比短信網關速度很差），那麼主流程的時間會加長不少，用戶確定不但願點擊支付過好幾分鐘纔看到結果。那麼咱們只須要通知短信系統「咱們支付成功了」，不必定非要等待它處理完成。

最終一致性

最終一致性指的是兩個系統的狀態保持一致，要麼都成功，要麼都失敗。固然有個時間限制，理論上越快越好，但實際上在各類異常的狀況下，可能會有必定延遲達到最終一致狀態，但最後兩個系統的狀態是同樣的。

業界有一些爲「最終一致性」而生的消息隊列，如Notify（阿里）、QMQ（去哪兒）等，其設計初衷，就是爲了交易系統中的高可靠通知。

以一個銀行的轉帳過程來理解最終一致性，轉帳的需求很簡單，若是A系統扣錢成功，則B系統加錢必定成功。反之則一塊兒回滾，像什麼都沒發生同樣。

然而，這個過程當中存在不少可能的意外：

1. A扣錢成功，調用B加錢接口失敗。
   
2. A扣錢成功，調用B加錢接口雖然成功，但獲取最終結果時網絡異常引發超時。
   
3. A扣錢成功，B加錢失敗，A想回滾扣的錢，但A機器down機。
   

可見，想把這件看似簡單的事真正作成，真的不那麼容易。全部跨VM的一致性問題，從技術的角度講通用的解決方案是：

1. 強一致性，分佈式事務，但落地太難且成本過高，後文會具體提到。
   
2. 最終一致性，主要是用「記錄」和「補償」的方式。在作全部的不肯定的事情以前，先把事情記錄下來，而後去作不肯定的事情，結果多是：成功、失敗或是不肯定，「不肯定」（例如超時等）能夠等價爲失敗。成功就能夠把記錄的東西清理掉了，對於失敗和不肯定，能夠依靠定時任務等方式把全部失敗的事情從新搞一遍，直到成功爲止。回到剛纔的例子，系統在A扣錢成功的狀況下，把要給B「通知」這件事記錄在庫裏（爲了保證最高的可靠性能夠把通知B系統加錢和扣錢成功這兩件事維護在一個本地事務裏），通知成功則刪除這條記錄，通知失敗或不肯定則依靠定時任務補償性地通知咱們，直到咱們把狀態更新成正確的爲止。整個這個模型依然能夠基於RPC來作，但能夠抽象成一個統一的模型，基於消息隊列來作一個「企業總線」。具體來講，本地事務維護業務變化和通知消息，一塊兒落地（失敗則一塊兒回滾），而後RPC到達broker，在broker成功落地後，RPC返回成功，本地消息能夠刪除。不然本地消息一直靠定時任務輪詢不斷重發，這樣就保證了消息可靠落地broker。broker往consumer發送消息的過程相似，一直髮送消息，直到consumer發送消費成功確認。咱們先不理會重複消息的問題，經過兩次消息落地加補償，下游是必定能夠收到消息的。而後依賴狀態機版本號等方式作判重，更新本身的業務，就實現了最終一致性。
   

最終一致性不是消息隊列的必備特性，但確實能夠依靠消息隊列來作最終一致性的事情。另外，全部不保證100%不丟消息的消息隊列，理論上沒法實現最終一致性。好吧，應該說理論上的100%，排除系統嚴重故障和bug。

像Kafka一類的設計，在設計層面上就有丟消息的可能（好比定時刷盤，若是掉電就會丟消息）。哪怕只丟千分之一的消息，業務也必須用其餘的手段來保證結果正確。

廣播

消息隊列的基本功能之一是進行廣播。若是沒有消息隊列，每當一個新的業務方接入，咱們都要聯調一次新接口。有了消息隊列，咱們只須要關心消息是否送達了隊列，至於誰但願訂閱，是下游的事情，無疑極大地減小了開發和聯調的工做量。

好比本文開始提到的產品中心發佈產品變動的消息，以及景點庫不少去重更新的消息，可能「關心」方有不少個，但產品中心和景點庫只須要發佈變動消息便可，誰關心誰接入。

錯峯與流控

試想上下游對於事情的處理能力是不一樣的。好比，Web前端每秒承受上千萬的請求，並非什麼神奇的事情，只須要加多一點機器，再搭建一些LVS負載均衡設備和Nginx等便可。但數據庫的處理能力卻十分有限，即便使用SSD加分庫分表，單機的處理能力仍然在萬級。因爲成本的考慮，咱們不能奢求數據庫的機器數量追上前端。

這種問題一樣存在於系統和系統之間，如短信系統可能因爲短板效應，速度卡在網關上（每秒幾百次請求），跟前端的併發量不是一個數量級。但用戶晚上個半分鐘左右收到短信，通常是不會有太大問題的。若是沒有消息隊列，兩個系統之間經過協商、滑動窗口等複雜的方案也不是說不能實現。但系統複雜性指數級增加，勢必在上游或者下游作存儲，而且要處理定時、擁塞等一系列問題。並且每當有處理能力有差距的時候，都須要單獨開發一套邏輯來維護這套邏輯。因此，利用中間系統轉儲兩個系統的通訊內容，並在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。

總而言之，消息隊列不是萬能的。對於須要強事務保證並且延遲敏感的，RPC是優於消息隊列的。

對於一些無關痛癢，或者對於別人很是重要可是對於本身不是那麼關心的事情，能夠利用消息隊列去作。

支持最終一致性的消息隊列，可以用來處理延遲不那麼敏感的「分佈式事務」場景，並且相對於笨重的分佈式事務，多是更優的處理方式。

當上下游系統處理能力存在差距的時候，利用消息隊列作一個通用的「漏斗」。在下游有能力處理的時候，再進行分發。

若是下游有不少系統關心你的系統發出的通知的時候，果斷地使用消息隊列吧。

• 美團雲知乎機構帳號 每日分享雲計算產品，技術內容。 
  
• 加入美團雲技術交流羣（QQ羣：469243579），每日分享更多精彩技術文章。