阿里巴巴消息中間件團隊消息和分佈式數據層負責人王晶昱：消息系統架構與變遷

對於大型的互聯網業務來講，消息系統是必不可少的基礎服務。 子柳 在《淘寶技術這十年》中爲你們展現了阿里消息系統架構的概貌，做爲集團業務使用的核心基礎服務，目前消息系統如今能夠承受天天幾百億規模的請求，並在歷年的雙11、雙十二大促中承受住抗住了更加嚴峻的考驗，消息系統背後的中間件團隊還陸續開源了諸如MetaQ、RocketMQ等項目。近期，InfoQ 採訪了阿里消息中間件團隊消息和分佈式數據層負責人王晶昱（花名：沈詢），話題涉及案例中間件系統的選型、系統擴容與數據一致性、團隊文化等內容。

InfoQ：對於阿里的消息中間件系統，你們所普遍瞭解的是@子柳 在《淘寶技術這十年》中介紹的Notify ，可是從最近的阿里的開源計劃中，咱們常常看到 MetaQ/RocketMQ ，在阿里內部 Notify和 MetaQ 是怎樣的關係？我看到早期的MetaQ是採用的Kafaka的設計思路，那麼可能你們就比較好奇「問什麼要重複造輪子」，能不能介紹這個方面的考慮以及所作的工做？

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

由於淘寶是個交易類網站，因此事務支持的特性可以很是方便的讓用戶能夠快速的依託於Notify完成他們本身的業務邏輯。

然而，一個產品不可能知足全部的場景，在當時咱們就常常收到一些須要保證消息有序的發送和接收的需求，而這樣的場景對於上來就定位於無序消息投遞的 Notify 來講無異於釜底抽薪。

而正在咱們討論這類需求應該如何被知足的時候，正好遇上 LinkedIn 的 KafKa 隊列開源，簡單的文件隊列，拉模型，保證順序的特性一下就吸引了咱們的目光，在對他的作了總體架構上的Review之後，咱們認爲這是個很是優雅的模型，由於他足夠簡單，簡單就是最好的~！

然而裏面也有一些特性不是咱們所須要的，好比咱們主要是面向內部用戶，所以按期輪詢去拉的方式就不適合咱們的實際場景需求，而且由於 KafKa 的開發語言是 Scala ，不大利於咱們的後續的維護，所以咱們借鑑了 Kafka 的核心思路，對其進行了重寫並開源，固然咱們仍是向 LinkedIn 的 KafKa 作了致敬的，MetaQ 實際上是 Metamorphosis 的意思，是Kafka的名做。

從上面的發展歷程其實也就可以比較清晰的找到兩個消息隊列產品的不一樣定位了：

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

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億元銷售奇蹟背後的每一筆交易訂單都和阿里中間件團隊的技術小二們息息相關。

中間件團隊致力於成爲中國第1、世界一流的Java技術團隊。自主研發的一系列產品始於07年末開始的淘寶架構 2.0 到 3.0 的變遷過程當中，使淘寶網 從集中式的 Java 應用走向了分佈式 Java 應用，涵蓋了消息中間件、服務框架、數據層、應用服務器和大規模分佈式穩定性平臺等等。解決了淘寶網這個大型系統中的應用間以及應用到水平拆分後的數據庫間的訪問問題，經過消息中間件對應用進行了解耦並提供了最終一致性支持。目前普遍使用在大淘寶的各個Java應用中以及少部分的非Java應用中。而穩定性平臺、性能優化平臺是在淘寶系統分佈式化後解決和穩定性、容量規劃、降級管理、依賴告警以及性能丈量等方面的問題的利器。

中間件團隊的同窗是一羣不安於現狀且喜歡折騰的人，未必很資深可是很執着，充滿熱情。你們來自五湖四海，到這裏一塊兒解決技術難題，提高系統性能，完成業務突破，構建新的應用，玩兒轉技術、業務、數據、無線。

若是你酷愛技術、喜歡鑽研、願意去幫助多個業務系統的發展，而且認爲編程是別人不能剝奪的權利的話，歡迎加入咱們，一塊兒提高咱們的技術產品，一塊兒去支持業務更好的發展。

若是你但願在淘寶的土壤上，用咱們的技術去折騰一些新應用，新玩兒法出來，也歡迎經過xiaoxie@taobao.com或者shenxun@taobao.com和咱們聯繫

InfoQ：您我的的經歷也是比較有意思，我看到在 ADC 2012 的分享中，您提到本身作過4年淘寶小2、參與淘寶全部去 O 項目、負責分佈式數據庫中間件團隊、到如今負責消息中間件團隊，能不能詳細介紹下本身成長的歷程？

沈詢：我當年是被這團隊的 Title 「騙」來的，當時中間件這個團隊的名字很是唬人： 「淘寶平臺架構組」，不能不說平臺架構這個名字對於剛畢業的學生來講確實是高大上啊~

其餘的事情其實更多地仍是在外部環境和本身的積累上。

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

InfoQ：做爲一個須要對阿里系的全部項目提供支撐服務的團隊，在選擇團隊成員的時候通常都會從哪些方面考量？如何確保對的人做對的事？

沈詢：首先，但願他是個技術人：畢竟這是個純粹的技術團隊，產品自己就是純粹的技術產品，所以計算機體系內知識，編程技巧方面的要求是首要的要求。

第二，但願他是個品行端正的正人君子，可以可以準確的把握本身的實際須要，擁有自我管理的能力，並能與其餘人進行合做，可以體諒其餘人的難處。

第三，但願他是個可以獨立解決未知問題的人、獨立思考、不人云亦云、活用知識，可以解決實際問題。

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

關於沈詢

沈詢實際上是個花名，原做裏叫沈洵，是個40多歲的白衣大俠，真實的我就是個普通的程序員，平時喜歡看一些雜書，天文地理海洋氣象歷史政治經濟都喜歡讀讀，在技術上主要仍是關注數據庫相關的業界最新進展。

【ArchSummit深圳2016】15大精彩專題，20位大咖講師，馭勢科技聯合創始人CEO吳甘沙、Twitter機器學習基礎設施組技術負責人郭曉江、騰訊平臺技術運營總監徐勇州、石墨文檔創始人吳潔..各大技術大咖齊聚ArchSummit，最精彩的技術切磋從這開始，八折門票倒計時，詳情請點擊這裏。