阿裡巴巴分布式消息系統的演進之路

阿裡中間件給客戶提供的是一套企業網際網路應用架構整體解決方案，裡面有很多元件，比如用來做分布式應用編寫的應用平台（EDAS），做可無限擴充的分布式資料庫（DRDS）和金融級可靠的消息隊列服務（AliMQ）。

這篇文章主要是希望給大家介紹一下阿裡巴巴中間件分布式消息系統（AliMQ）這塊的一些基本情況。從消息系統在阿裡内的應用情況，解決了什麼問題，具體解決問題的原理是什麼等方面做一些分享。

對于大型的網際網路業務來說，消息系統是必不可少的基礎服務。 子柳 在《淘寶技術這十年》中為大家展示了阿裡消息系統架構的概貌，作為集團業務使用的核心基礎服務，目前消息系統現在可以承受每天幾百億規模的請求，并在曆年的雙十一、雙十二大促中承受住抗住了更加嚴峻的考驗，消息系統背後的中間件團隊還陸續開源了諸如MetaQ、RocketMQ等項目。

InfoQ：對于阿裡的消息中間件系統，大家所廣泛了解的是《淘寶技術這十年》中介紹的 Notify ，但是從阿裡的開源計劃中，我們經常看到MetaQ，在阿裡内部 Notify 和 MetaQ 是怎樣的關系？

沈詢：要講明白這個問題，就需要從産品的實際需求角度入手開始做個介紹了。Notify作為一個已經存在了5年多的消息産品，被廣泛的應用在整個阿裡巴巴集團的大部分消息通信領域。它的核心特性是： 提供事務支援、不保證消息順序、消息可能會重複、推模型。

因為淘寶是個交易類網站，是以事務支援的特性能夠非常友善的讓使用者可以快速的依托于Notify完成他們自己的業務邏輯。

然而，一個産品不可能滿足所有的場景，在當時我們就經常收到一些需要保證消息有序的發送和接收的需求，而這樣的場景對于上來就定位于無序消息投遞的 Notify 來說無異于釜底抽薪。

而正在我們讨論這類需求應該如何被滿足的時候，正好趕上 LinkedIn 的 KafKa 隊列開源，簡單的檔案隊列，拉模型，保證順序的特性一下就吸引了我們的目光，在對他的做了整體架構上的Review以後，我們認為這是個非常優雅的模型，因為他足夠簡單，簡單就是最好的~！

然而裡面也有一些特性不是我們所需要的，比如我們主要是面向内部使用者，是以定期輪詢去拉的方式就不适合我們的實際場景需求，并且因為 KafKa 的開發語言是 Scala ，不大利于我們的後續的維護，是以我們借鑒了 Kafka 的核心思路，對其進行了重寫并開源，當然我們還是向 LinkedIn 的 KafKa 做了緻敬的，MetaQ 其實是 Metamorphosis 的意思，是Kafka的名作。

從上面的發展曆程其實也就能夠比較清晰的找到兩個消息隊列産品的不同定位了：

• RocketMQ（MetaQ）主要面向消息有序的場景，能夠提供更大的消息堆積能力。
• Notify，主要面向需要更加安全可靠地交易類場景，無序，推模式。

目前 ，我們也将這套消息系統放在了雲上，https://www.aliyun.com/product/ons/ 額外增加了更高的安全性保證，大家也可以看看。

InfoQ：您個人在分布式方面有比較多的經驗，而消息系統中一個重要的考慮因素就是分布式的擴充能力，尤其是對于阿裡、淘寶的業務，能不能介紹下目前中間件團隊在分布式是如何做的？跨域、跨機房方面？

沈詢：其實所謂分布式運算，核心的思路就是系統架構無單點， 讓整個系統可擴充。

如果要介紹分布式場景的實際經驗，那麼我就需要先引入一個概念：“有狀态存儲節點和無狀态運算節點”。

無狀态運算節點主要是部署 Web 應用、 HSF 服務，消息隊列等的機器有狀态的存儲節點主要是指部署資料庫、緩存、配置伺服器、 NoSQL 等的機器。

那麼針對無狀态節點，因為不存儲資料，請求分發可以采取很簡單的随機算法或者是輪詢的算法就可以了，如果需要增加機器，那隻需要把對應的運算代碼部署到一些機器上，然後啟動起來，引導流量到那些機器上就可以實作動态的擴充了，是以一般來說在無狀态的節點的擴充是相對的容易的，唯一需要做的事情就是在某個機器承擔了某種角色以後，能夠快速的廣播給需要這個角色提供服務的人說：“我目前可以做這個活兒啦，你們有需要我做事兒的人，可以來找我。”

而針對有狀态節點，擴容的難度就相對的大一些，因為每台 Server 中都有資料，是以請求分發的算法不能夠用随機或者是輪詢了，一般來說常見算法就是哈希或者是使用 Tree 來做一層映射，而如果需要增加機器，那麼需要一個比較複雜的資料遷移的過程，而遷移資料本身所需要的成本是非常高的，這也就直接導緻有狀态節點的擴容難度比無狀态節點更大。

針對有狀态節點的難題，我們提供了一套資料自動擴容和遷移的工具來滿足使用者的自動擴容縮容中所産生的資料遷移類的需求。 于是，無論是有狀态的資料節點的擴容，還是無狀态的資料節點的自動擴容，我們都可以使用自動化工具來完成了。

在所有的節點都能夠實作自動的擴容以後，整個體系就能夠水準的進行擴充了。這種架構很好的支援了我們曆年的雙11大促，而且每年都有一些進步。然而，這套模式也不是萬能藥，在當下，杭州已經很難滿足我們對機器的全部需求了。

為此，我們也在嘗試進行異地資料中心的嘗試，以期能夠将一部分運算和存儲能力搬運到異地機房進行。

提到異地資料中心，一般第一個會被想到的是 Google 的 Spanner，這套系統是一個跨資料中心的強一緻資料庫系統，然而我們在經過仔細的考量以後，認為在目前的情況下，使用這種方式并不能夠解決一個大規模線上交易類網站對于高并發TPS的實際需求，是以我們選擇了另外的方式來實作跨資料中心的事務模式。

其核心思想也很簡單，即是将資料放置在距離使用者最近的機房裡面，并盡可能減少應用層的跨機房調用，以充分提高性能，降低延遲。

InfoQ：消息系統在保證資料的一緻性方面做了哪些工作？

沈詢：一緻性這是個說複雜，挺複雜；說簡單，也挺簡單的領域。要了解一緻性，其實關鍵在一個“看”字，一緻性限制的是一個使用者寫入并送出資料之後，其他使用者去讀這條記錄的時候，要麼看到的是事務開始之前的狀态，要麼就是事務結束後的狀态，而在這兩個狀态之間的事務狀态則不會被其他人看到。

我們以一個例子做說明：

李雷要給韓梅梅100元，那麼，要麼結果是韓梅梅有100元，要麼是李雷有100元，而李雷減少了100元，但韓梅梅還沒加上這100塊的這個中間狀态則不能夠被其他人看到。

做到這個一緻性的一般性做法就是把資料加鎖，讓某個資料隻能被某個程序或線程通路就行了。但這樣也有個代價就是鎖住資料的時間越長，系統的并發程度越低，系統的tps也就越低了。尤其在分布式場景下，維持鎖的延遲在加入了網絡這個因素後，變得非常巨大，以至于很難接受。

是以在網際網路行業中，大家普遍使用的方式是“最終一緻”，也就是，三種狀态都有可能出現，但李雷減少了100元，韓梅梅卻沒加上100元這個狀态，因為速度非常快，隻有毫秒級，并且對使用者沒有太多的不良影響，是以就認為是允許了。

使用者可見的狀态，從原來的兩個狀态，變成了三個狀态。

然而需要注意的是，最終一緻并不意味着弱一緻，也就是說，韓梅梅“最終”必須能夠拿到這筆錢，能夠拿到，就是“最終”一緻，在異常狀态下不能夠拿到，那就是“弱”一緻。

消息系統的作用，就在于能夠将“弱”一緻變成“最終”一緻，保證多方資料的狀态的最終正确性。

InfoQ： 目前消息中間件的使用規模是怎樣的？目前的吞吐量、負載如何？在中間件部落格中提到了雙12期間中間件在彩票活動中所起的總用，是否能夠詳細介紹下在兩次大促期間，中間件團隊所做的工作？遇到的問題以及應對方案？

沈詢：基本上整個阿裡集團都在使用我們的中間件所提供的服務，消息規模在幾百億每天，高峰期 load 在4~5左右。

在大促過程中，消息中間件主要起到了蓄水池的作用，投遞消息的往往都是核心應用，機器會優先保證，處理能力強勁，而接受消息的應用則可能存在處理不過來的情況，是以業務請求會在消息中間件中做一次削峰的操作，進而可以保證後端系統不會因為前端流量過載而導緻系統不可用。

InfoQ：目前所在的團隊具體負責哪些工作？團隊組成是怎樣的？如何分工？業務擴充方向是怎樣的？

沈詢：阿裡中間件團隊，是國内為數不多的極具技術挑戰性的團隊之一，依托于全球規模最大的阿裡巴巴電子商務平台所帶來的巨大流量和海量資料，以及對于電子商務平台固有的穩定性要求，使得團隊有機會去面對一個又一個技術難題，創造一個又一個技術奇迹。在剛剛過去的“2013雙十一網購狂歡節”中，350億元銷售奇迹背後的每一筆交易訂單都和阿裡中間件團隊的技術小二們息息相關。

中間件團隊緻力于成為中國第一、世界一流的Java技術團隊。自主研發的一系列産品始于07年底開始的淘寶架構 2.0 到 3.0 的變遷過程中，使淘寶網 從集中式的 Java 應用走向了分布式 Java 應用，涵蓋了消息中間件、服務架構、資料層、應用伺服器和大規模分布式穩定性平台等等

解決了淘寶網這個大型系統中的應用間以及應用到水準拆分後的資料庫間的通路問題，通過消息中間件對應用進行了解耦并提供了最終一緻性支援。目前廣泛使用在大淘寶的各個Java應用中以及少部分的非Java應用中。而穩定性平台、性能優化平台是在淘寶系統分布式化後解決和穩定性、容量規劃、降級管理、依賴告警以及性能丈量等方面的問題的利器。

中間件團隊的同學是一群不安于現狀且喜歡折騰的人，未必很資深但是很執着，充滿熱情。大家來自五湖四海，到這裡一起解決技術難題，提升系統性能，完成業務突破，建構新的應用，玩兒轉技術、業務、資料、無線。

如果你酷愛技術、喜歡鑽研、願意去幫助多個業務系統的發展，并且認為程式設計是别人不能剝奪的權利的話，歡迎加入我們，一起提升我們的技術産品，一起去支援業務更好的發展。

InfoQ：您個人的經曆也是比較有意思，我看到在 ADC 2012 的分享中，您提到自己做過4年淘寶小二、參與淘寶所有去 O 項目、負責分布式資料庫中間件團隊、到現在負責消息中間件團隊，能不能詳細介紹下自己成長的曆程？

沈詢：我當年是被這團隊的 Title “騙”來的，當時中間件這個團隊的名字非常唬人： “淘寶平台架構組”，不能不說平台架構這個名字對于剛畢業的學生來說确實是高大上啊~

其他的事情其實更多地還是在外部環境和自己的積累上。

能夠趕上這樣快速發展并且需求多種多樣的應用場景，不能不說是一個程式員最幸福的事情，盡管也會偶爾為了解決一個線上問題在高度緊張下線上上操作到深夜等這類問題，不過當你回頭看看，會發現過程本身其實就是個積累的時刻，碰到并解決的坑越多，加上自己的一些思考與探索，自然就會有一定建樹。

InfoQ：作為一個需要對阿裡系的所有項目提供支撐服務的團隊，在選擇團隊成員的時候一般都會從哪些方面考量？如何確定對的人作對的事？

沈詢：首先，希望他是個技術人：畢竟這是個純粹的技術團隊，産品本身就是純粹的技術産品，是以計算機體系内知識，程式設計技巧方面的要求是首要的要求。

第二，希望他是個品行端正的正人君子，能夠能夠準确的把握自己的實際需要，擁有自我管理的能力，并能與其他人進行合作，能夠體諒其他人的難處。

第三，希望他是個能夠獨立解決未知問題的人、獨立思考、不人雲亦雲、活用知識，能夠解決實際問題。

在用人上面，我們比較關注每個人自己的主觀能動性，畢竟興趣是最好的老師，是以個人的需求會優先被考慮。當然，團隊本身客觀上會有一些不得不去做的事情，不過這種情況下也會在充分尊重個人意願的情況下做好溝通性工作的。

關于沈詢

沈詢其實是個花名，在原著裡是個40多歲的白衣大俠，平時真實的我就是個普通的程式員，平時喜歡看一些雜書，天文地理海洋氣象曆史政治經濟都喜歡讀讀，在技術上主要還是關注資料庫相關的業界最新進展。