沈詢：要講明白這個問題，就需要從產(chǎn)品的實際需求角度入手開始做個介紹了。Notify作為一個已經(jīng)存在了5年多的消息產(chǎn)品，被廣泛的應(yīng)用在整個阿里巴巴集團的大部分消息通信領(lǐng)域。它的核心特性是： 提供事務(wù)支持、不保證消息順序、消息可能會重復(fù)、推模型。

因為淘寶是個交易類網(wǎng)站，所以事務(wù)支持的特性能夠非常方便的讓用戶可以快速的依托于Notify完成他們自己的業(yè)務(wù)邏輯。

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

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

然而里面也有一些特性不是我們所需要的，比如我們主要是面向內(nèi)部用戶，因此定期輪詢?nèi)ダ姆绞骄筒贿m合我們的實際場景需求，并且因為 KafKa 的開發(fā)語言是 Scala ，不大利于我們的后續(xù)的維護，因此我們借鑒了 Kafka 的核心思路，對其進行了重寫并開源，當然我們還是向 LinkedIn 的 KafKa 做了致敬的，MetaQ 其實是 Metamorphosis 的意思，是Kafka的名作。

從上面的發(fā)展歷程其實也就能夠比較清晰的找到兩個消息隊列產(chǎn)品的不同定位了：

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

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

沈詢：其實所謂分布式運算，核心的思路就是系統(tǒng)架構(gòu)無單點， 讓整個系統(tǒng)可擴展。

如果要介紹分布式場景的實際經(jīng)驗，那么我就需要先引入一個概念：“有狀態(tài)存儲節(jié)點和無狀態(tài)運算節(jié)點”。

無狀態(tài)運算節(jié)點主要是部署 Web 應(yīng)用、 HSF 服務(wù)，消息隊列等的機器有狀態(tài)的存儲節(jié)點主要是指部署數(shù)據(jù)庫、緩存、配置服務(wù)器、 NoSQL 等的機器。

那么針對無狀態(tài)節(jié)點，因為不存儲數(shù)據(jù)，請求分發(fā)可以采取很簡單的隨機算法或者是輪詢的算法就可以了，如果需要增加機器，那只需要把對應(yīng)的運算代碼部署到一些機器上，然后啟動起來，引導(dǎo)流量到那些機器上就可以實現(xiàn)動態(tài)的擴展了，所以一般來說在無狀態(tài)的節(jié)點的擴展是相對的容易的，唯一需要做的事情就是在某個機器承擔(dān)了某種角色以后，能夠快速的廣播給需要這個角色提供服務(wù)的人說：“我目前可以做這個活兒啦，你們有需要我做事兒的人，可以來找我。”

而針對有狀態(tài)節(jié)點，擴容的難度就相對的大一些，因為每臺 Server 中都有數(shù)據(jù)，所以請求分發(fā)的算法不能夠用隨機或者是輪詢了，一般來說常見算法就是哈希或者是使用 Tree 來做一層映射，而如果需要增加機器，那么需要一個比較復(fù)雜的數(shù)據(jù)遷移的過程，而遷移數(shù)據(jù)本身所需要的成本是非常高的，這也就直接導(dǎo)致有狀態(tài)節(jié)點的擴容難度比無狀態(tài)節(jié)點更大。

針對有狀態(tài)節(jié)點的難題，我們提供了一套數(shù)據(jù)自動擴容和遷移的工具來滿足用戶的自動擴容縮容中所產(chǎn)生的數(shù)據(jù)遷移類的需求。 于是，無論是有狀態(tài)的數(shù)據(jù)節(jié)點的擴容，還是無狀態(tài)的數(shù)據(jù)節(jié)點的自動擴容，我們都可以使用自動化工具來完成了。

在所有的節(jié)點都能夠?qū)崿F(xiàn)自動的擴容以后，整個體系就能夠水平的進行擴展了。這種架構(gòu)很好的支持了我們歷年的雙11大促，而且每年都有一些進步。然而，這套模式也不是萬能藥，在當下，杭州已經(jīng)很難滿足我們對機器的全部需求了。

為此，我們也在嘗試進行異地數(shù)據(jù)中心的嘗試，以期能夠?qū)⒁徊糠诌\算和存儲能力搬運到異地機房進行。

提到異地數(shù)據(jù)中心，一般第一個會被想到的是 Google 的 Spanner，這套系統(tǒng)是一個跨數(shù)據(jù)中心的強一致數(shù)據(jù)庫系統(tǒng)，然而我們在經(jīng)過仔細的考量以后，認為在目前的情況下，使用這種方式并不能夠解決一個大規(guī)模在線交易類網(wǎng)站對于高并發(fā)TPS的實際需求，因此我們選擇了另外的方式來實現(xiàn)跨數(shù)據(jù)中心的事務(wù)模式。

其核心思想也很簡單，即是將數(shù)據(jù)放置在距離用戶最近的機房里面，并盡可能減少應(yīng)用層的跨機房調(diào)用，以充分提高性能，降低延遲。

InfoQ：消息系統(tǒng)在保證數(shù)據(jù)的一致性方面做了哪些工作？

沈詢：一致性這是個說復(fù)雜，挺復(fù)雜；說簡單，也挺簡單的領(lǐng)域。要理解一致性，其實關(guān)鍵在一個“看”字，一致性約束的是一個用戶寫入并提交數(shù)據(jù)之后，其他用戶去讀這條記錄的時候，要么看到的是事務(wù)開始之前的狀態(tài)，要么就是事務(wù)結(jié)束后的狀態(tài)，而在這兩個狀態(tài)之間的事務(wù)狀態(tài)則不會被其他人看到。

我們以一個例子做說明：

李雷要給韓梅梅100元，那么，要么結(jié)果是韓梅梅有100元，要么是李雷有100元，而李雷減少了100元，但韓梅梅還沒加上這100塊的這個中間狀態(tài)則不能夠被其他人看到。

做到這個一致性的一般性做法就是把數(shù)據(jù)加鎖，讓某個數(shù)據(jù)只能被某個進程或線程訪問就行了。但這樣也有個代價就是鎖住數(shù)據(jù)的時間越長，系統(tǒng)的并發(fā)程度越低，系統(tǒng)的tps也就越低了。尤其在分布式場景下，維持鎖的延遲在加入了網(wǎng)絡(luò)這個因素后，變得非常巨大，以至于很難接受。

因此在互聯(lián)網(wǎng)行業(yè)中，大家普遍使用的方式是“最終一致”，也就是，三種狀態(tài)都有可能出現(xiàn)，但李雷減少了100元，韓梅梅卻沒加上100元這個狀態(tài)，因為速度非常快，只有毫秒級，并且對用戶沒有太多的不良影響，所以就認為是允許了。

用戶可見的狀態(tài)，從原來的兩個狀態(tài)，變成了三個狀態(tài)。

然而需要注意的是，最終一致并不意味著弱一致，也就是說，韓梅梅“最終”必須能夠拿到這筆錢，能夠拿到，就是“最終”一致，在異常狀態(tài)下不能夠拿到，那就是“弱”一致。

消息系統(tǒng)的作用，就在于能夠?qū)ⅰ叭酢币恢伦兂伞白罱K”一致，保證多方數(shù)據(jù)的狀態(tài)的最終正確性。

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

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

在大促過程中，消息中間件主要起到了蓄水池的作用，投遞消息的往往都是核心應(yīng)用，機器會優(yōu)先保證，處理能力強勁，而接受消息的應(yīng)用則可能存在處理不過來的情況，因此業(yè)務(wù)請求會在消息中間件中做一次削峰的操作，從而可以保證后端系統(tǒng)不會因為前端流量過載而導(dǎo)致系統(tǒng)不可用。

InfoQ：目前所在的團隊具體負責(zé)哪些工作？團隊組成是怎樣的？如何分工？業(yè)務(wù)擴展方向是怎樣的？

沈詢：阿里中間件團隊，是國內(nèi)為數(shù)不多的極具技術(shù)挑戰(zhàn)性的團隊之一，依托于全球規(guī)模最大的阿里巴巴電子商務(wù)平臺所帶來的巨大流量和海量數(shù)據(jù)，以及對于電子商務(wù)平臺固有的穩(wěn)定性要求，使得團隊有機會去面對一個又一個技術(shù)難題，創(chuàng)造一個又一個技術(shù)奇跡。在剛剛過去的“2013雙十一網(wǎng)購狂歡節(jié)”中，350億元銷售奇跡背后的每一筆交易訂單都和阿里中間件團隊的技術(shù)小二們息息相關(guān)。

中間件團隊致力于成為中國第一、世界一流的Java技術(shù)團隊。自主研發(fā)的一系列產(chǎn)品始于07年底開始的淘寶架構(gòu) 2.0 到 3.0 的變遷過程中，使淘寶網(wǎng) 從集中式的 Java 應(yīng)用走向了分布式 Java 應(yīng)用，涵蓋了消息中間件、服務(wù)框架、數(shù)據(jù)層、應(yīng)用服務(wù)器和大規(guī)模分布式穩(wěn)定性平臺等等。解決了淘寶網(wǎng)這個大型系統(tǒng)中的應(yīng)用間以及應(yīng)用到水平拆分后的數(shù)據(jù)庫間的訪問問題，通過消息中間件對應(yīng)用進行了解耦并提供了最終一致性支持。目前廣泛使用在大淘寶的各個Java應(yīng)用中以及少部分的非Java應(yīng)用中。而穩(wěn)定性平臺、性能優(yōu)化平臺是在淘寶系統(tǒng)分布式化后解決和穩(wěn)定性、容量規(guī)劃、降級管理、依賴告警以及性能丈量等方面的問題的利器。

中間件團隊的同學(xué)是一群不安于現(xiàn)狀且喜歡折騰的人，未必很資深但是很執(zhí)著，充滿熱情。大家來自五湖四海，到這里一起解決技術(shù)難題，提升系統(tǒng)性能，完成業(yè)務(wù)突破，構(gòu)建新的應(yīng)用，玩兒轉(zhuǎn)技術(shù)、業(yè)務(wù)、數(shù)據(jù)、無線。

如果你酷愛技術(shù)、喜歡鉆研、愿意去幫助多個業(yè)務(wù)系統(tǒng)的發(fā)展，并且認為編程是別人不能剝奪的權(quán)利的話，歡迎加入我們，一起提升我們的技術(shù)產(chǎn)品，一起去支持業(yè)務(wù)更好的發(fā)展。

如果你希望在淘寶的土壤上，用我們的技術(shù)去折騰一些新應(yīng)用，新玩兒法出來，也歡迎通過xiaoxie@taobao.com或者shenxun@taobao.com和我們聯(lián)系

InfoQ：您個人的經(jīng)歷也是比較有意思，我看到在 ADC 2012 的分享中，您提到自己做過4年淘寶小二、參與淘寶所有去 O 項目、負責(zé)分布式數(shù)據(jù)庫中間件團隊、到現(xiàn)在負責(zé)消息中間件團隊，能不能詳細介紹下自己成長的歷程？

沈詢：我當年是被這團隊的 Title “騙”來的，當時中間件這個團隊的名字非常唬人： “淘寶平臺架構(gòu)組”，不能不說平臺架構(gòu)這個名字對于剛畢業(yè)的學(xué)生來說確實是高大上啊~

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

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

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

沈詢：首先，希望他是個技術(shù)人：畢竟這是個純粹的技術(shù)團隊，產(chǎn)品本身就是純粹的技術(shù)產(chǎn)品，因此計算機體系內(nèi)知識，編程技巧方面的要求是首要的要求。

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

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

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

關(guān)于沈詢

沈詢其實是個花名，原作里叫沈洵，是個40多歲的白衣大俠，真實的我就是個普通的程序員，平時喜歡看一些雜書，天文地理海洋氣象歷史政治經(jīng)濟都喜歡讀讀，在技術(shù)上主要還是關(guān)注數(shù)據(jù)庫相關(guān)的業(yè)界最新進展。

阿里巴巴開源地址：https://github.com/alibaba/