阿里中間件給客戶提供的是一套企業互聯網應用架構整體解決方案，里面有很多組件，比如用來做分布式應用編寫的應用平臺（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多歲的白衣大俠，平時真實的我就是個普通的程序員，平時喜歡看一些雜書，天文地理海洋氣象歷史政治經濟都喜歡讀讀，在技術上主要還是關注數據庫相關的業界最新進展。
