聲明：本人非阿里員工，只是震撼於阿里在雙十一處理高併發的能力，在網上查看一些雙十一的技術進行總結。我是大自然的搬運工。
2013年雙十一，阿里還是用的mysql數據庫，服務器主要技術如下
雙“11”最熱門的話題是TB ，最近正好和阿里的一個朋友聊淘寶的技術架構，發現很多有意思的地方，分享一下他們的解析資料：
淘寶海量數據產品技術架構
數據產品的一個最大特點是數據的非實時寫入，正因爲如此，我們可以認爲，在一定的時間段內，整個系統的數據是隻讀的。這爲我們設計緩存奠定了非常重要的基礎。
圖1 淘寶海量數據產品技術架構
按照數據的流向來劃分，我們把淘寶數據產品的技術架構分爲五層（如圖1所示），分別是數據源、計算層、存儲層、查詢層和產品層。位於架構頂端的是我們的數據來源層，這裏有淘寶主站的用戶、店鋪、商品和交易等數據庫，還有用戶的瀏覽、搜索等行爲日誌等。這一系列的數據是數據產品最原始的生命力所在。
在數據源層實時產生的數據，通過淘寶自主研發的數據傳輸組件DataX、DbSync和Timetunnel準實時地傳輸到一個有1500個節點的Hadoop集羣上，這個集羣我們稱之爲“雲梯”，是計算層的主要組成部分。在“雲梯”上，我們每天有大約40000個作業對1.5PB的原始數據按照產品需求進行不同的MapReduce計算。這一計算過程通常都能在凌晨兩點之前完成。相對於前端產品看到的數據，這裏的計算結果很可能是一個處於中間狀態的結果，這往往是在數據冗餘與前端計算之間做了適當平衡的結果。
不得不提的是，一些對實效性要求很高的數據，例如針對搜索詞的統計數據，我們希望能儘快推送到數據產品前端。這種需求再採用“雲梯”來計算效率將是比較低的，爲此我們做了流式數據的實時計算平臺，稱之爲“銀河”。“銀河”也是一個分佈式系統，它接收來自TimeTunnel的實時消息，在內存中做實時計算，並把計算結果在儘可能短的時間內刷新到NoSQL存儲設備中，供前端產品調用。
容易理解，“雲梯”或者“銀河”並不適合直接向產品提供實時的數據查詢服務。這是因爲，對於“雲梯”來說，它的定位只是做離線計算的，無法支持較高的性能和併發需求；而對於“銀河”而言，儘管所有的代碼都掌握在我們手中，但要完整地將數據接收、實時計算、存儲和查詢等功能集成在一個分佈式系統中，避免不了分層，最終仍然落到了目前的架構上。
爲此，我們針對前端產品設計了專門的存儲層。在這一層，我們有基於MySQL的分佈式關係型數據庫集羣MyFOX和基於HBase的NoSQL存儲集羣Prom，在後面的文字中，我將重點介紹這兩個集羣的實現原理。除此之外，其他第三方的模塊也被我們納入存儲層的範疇。
存儲層異構模塊的增多，對前端產品的使用帶來了挑戰。爲此，我們設計了通用的數據中間層——glider——來屏蔽這個影響。glider以HTTP協議對外提供restful方式的接口。數據產品可以通過一個唯一的URL獲取到它想要的數據。
以上是淘寶海量數據產品在技術架構方面的一個概括性的介紹，接下來我將重點從四個方面闡述數據魔方設計上的特點。
關係型數據庫仍然是王道
關係型數據庫（RDBMS）自20世紀70年代提出以來，在工業生產中得到了廣泛的使用。經過三十多年的長足發展，誕生了一批優秀的數據庫軟件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。
圖2 MyFOX中的數據增長曲線
儘管相對於非關係型數據庫而言，關係型數據庫在分區容忍性（Tolerance to Network Partitions）方面存在劣勢，但由於它強大的語義表達能力以及數據之間的關係表達能力，在數據產品中仍然佔據着不可替代的作用。
淘寶數據產品選擇MySQL的MyISAM引擎作爲底層的數據存儲引擎。在此基礎上，爲了應對海量數據，我們設計了分佈式MySQL集羣的查詢代理層——MyFOX，使得分區對前端應用透明。
圖3 MyFOX的數據查詢過程
目前，存儲在MyFOX中的統計結果數據已經達到10TB，佔據着數據魔方總數據量的95%以上，並且正在以每天超過6億的增量增長着（如圖2所示）。這些數據被我們近似均勻地分佈到20個MySQL節點上，在查詢時，經由MyFOX透明地對外服務（如圖3所示）。
圖4 MyFOX節點結構
值得一提的是，在MyFOX現有的20個節點中，並不是所有節點都是“平等”的。一般而言，數據產品的用戶更多地只關心“最近幾天”的數據，越早的數據，越容易被冷落。爲此，出於硬件成本考慮，我們在這20個節點中分出了“熱節點”和“冷節點”（如圖4所示）。
顧名思義，“熱節點”存放最新的、被訪問頻率較高的數據。對於這部分數據，我們希望能給用戶提供儘可能快的查詢速度，所以在硬盤方面，我們選擇了每分鐘15000轉的SAS硬盤，按照一個節點兩臺機器來計算，單位數據的存儲成本約爲4.5W/TB。相對應地，“冷數據”我們選擇了每分鐘7500轉的SATA硬盤，單碟上能夠存放更多的數據，存儲成本約爲1.6W/TB。
將冷熱數據進行分離的另外一個好處是可以有效提高內存磁盤比。從圖4可以看出，“熱節點”上單機只有24GB內存，而磁盤裝滿大約有1.8TB（300 * 12 * 0.5 / 1024），內存磁盤比約爲4:300，遠遠低於MySQL服務器的一個合理值。內存磁盤比過低導致的後果是，總有一天，即使所有內存用完也存不下數據的索引了——這個時候，大量的查詢請求都需要從磁盤中讀取索引，效率大打折扣。
NoSQL是SQL的有益補充
在MyFOX出現之後，一切都看起來那麼完美，開發人員甚至不會意識到MyFOX的存在，一條不用任何特殊修飾的SQL語句就可以滿足需求。這個狀態持續了很長一段時間，直到有一天，我們碰到了傳統的關係型數據庫無法解決的問題——全屬性選擇器（如圖5所示）。
圖5 全屬性選擇器
這是一個非常典型的例子。爲了說明問題，我們仍然以關係型數據庫的思路來描述。對於筆記本電腦這個類目，用戶某一次查詢所選擇的過濾條件可能包括“筆記本尺寸”、“筆記本定位”、“硬盤容量”等一系列屬性（字段），並且在每個可能用在過濾條件的屬性上，屬性值的分佈是極不均勻的。在圖5中我們可以看到，筆記本電腦的尺寸這一屬性有着10個枚舉值，而“藍牙功能”這個屬性值是個布爾值，數據的篩選性非常差。
在用戶所選擇的過濾條件不確定的情況下，解決全屬性問題的思路有兩個：一個是窮舉所有可能的過濾條件組合，在“雲梯”上進行預先計算，存入數據庫供查詢；另一個是存儲原始數據，在用戶查詢時根據過濾條件篩選出相應的記錄進行現場計算。很明顯，由於過濾條件的排列組合幾乎是無法窮舉的，第一種方案在現實中是不可取的；而第二種方案中，原始數據存儲在什麼地方？如果仍然用關係型數據庫，那麼你打算怎樣爲這個表建立索引？
這一系列問題把我們引到了“創建定製化的存儲、現場計算並提供查詢服務的引擎”的思路上來，這就是Prometheus（如圖6所示）。
圖6 Prom的存儲結構
從圖6可以看出，我們選擇了HBase作爲Prom的底層存儲引擎。之所以選擇HBase，主要是因爲它是建立在HDFS之上的，並且對於MapReduce有良好的編程接口。儘管Prom是一個通用的、解決共性問題的服務框架，但在這裏，我們仍然以全屬性選擇爲例，來說明Prom的工作原理。這裏的原始數據是前一天在淘寶上的交易明細，在HBase集羣中，我們以屬性對（屬性與屬性值的組合）作爲row-key進行存儲。而row-key對應的值，我們設計了兩個column-family，即存放交易ID列表的index字段和原始交易明細的data字段。在存儲的時候，我們有意識地讓每個字段中的每一個元素都是定長的，這是爲了支持通過偏移量快速地找到相應記錄，避免複雜的查找算法和磁盤的大量隨機讀取請求。
圖7 Prom查詢過程
圖7用一個典型的例子描述的Prom在提供查詢服務時的工作原理，限於篇幅，這裏不做詳細描述。值得一提的是，Prom支持的計算並不僅限於求和SUM運算，統計意義上的常用計算都是支持的。在現場計算方面，我們對HBase進行了擴展，Prom要求每個節點返回的數據是已經經過“本地計算”的局部最優解，最終的全局最優解只是各個節點返回的局部最優解的一個簡單彙總。很顯然，這樣的設計思路是要充分利用各個節點的並行計算能力，並且避免大量明細數據的網絡傳輸開銷。
用中間層隔離前後端
上文提到過，MyFOX和Prom爲數據產品的不同需求提供了數據存儲和底層查詢的解決方案，但隨之而來的問題是，各種異構的存儲模塊給前端產品的使用帶來了很大的挑戰。並且，前端產品的一個請求所需要的數據往往不可能只從一個模塊獲取。
舉個例子，我們要在數據魔方中看昨天做熱銷的商品，首先從MyFOX中拿到一個熱銷排行榜的數據，但這裏的“商品”只是一個ID，並沒有ID所對應的商品描述、圖片等數據。這個時候我們要從淘寶主站提供的接口中去獲取這些數據，然後一一對應到熱銷排行榜中，最終呈現給用戶。
圖8 glider的技術架構
有經驗的讀者一定可以想到，從本質上來講，這就是廣義上的異構“表”之間的JOIN操作。那麼，誰來負責這個事情呢？很容易想到，在存儲層與前端產品之間增加一箇中間層，它負責各個異構“表”之間的數據JOIN和UNION等計算，並且隔離前端產品和後端存儲，提供統一的數據查詢服務。這個中間層就是glider（如圖8所示）。
緩存是系統化的工程
除了起到隔離前後端以及異構“表”之間的數據整合的作用之外，glider的另外一個不容忽視的作用便是緩存管理。上文提到過，在特定的時間段內，我們認爲數據產品中的數據是隻讀的，這是利用緩存來提高性能的理論基礎。
在圖8中我們看到，glider中存在兩層緩存，分別是基於各個異構“表”（datasource）的二級緩存和整合之後基於獨立請求的一級緩存。除此之外，各個異構“表”內部可能還存在自己的緩存機制。細心的讀者一定注意到了圖3中MyFOX的緩存設計，我們沒有選擇對彙總計算後的最終結果進行緩存，而是針對每個分片進行緩存，其目的在於提高緩存的命中率，並且降低數據的冗餘度。
大量使用緩存的最大問題就是數據一致性問題。如何保證底層數據的變化在儘可能短的時間內體現給最終用戶呢？這一定是一個系統化的工程，尤其對於分層較多的系統來說。
圖9 緩存控制體系
圖9向我們展示了數據魔方在緩存控制方面的設計思路。用戶的請求中一定是帶了緩存控制的“命令”的，這包括URL中的query string，和HTTP頭中的“If-None-Match”信息。並且，這個緩存控制“命令”一定會經過層層傳遞，最終傳遞到底層存儲的異構“表”模塊。各異構“表”除了返回各自的數據之外，還會返回各自的數據緩存過期時間（ttl），而glider最終輸出的過期時間是各個異構“表”過期時間的最小值。這一過期時間也一定是從底層存儲層層傳遞，最終通過HTTP頭返回給用戶瀏覽器的。
緩存系統不得不考慮的另一個問題是緩存穿透與失效時的雪崩效應。緩存穿透是指查詢一個一定不存在的數據，由於緩存是不命中時被動寫的，並且出於容錯考慮，如果從存儲層查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。
有很多種方法可以有效地解決緩存穿透問題，最常見的則是採用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。在數據魔方里，我們採用了一個更爲簡單粗暴的方法，如果一個查詢返回的數據爲空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。
緩存失效時的雪崩效應對底層系統的衝擊非常可怕。遺憾的是，這個問題目前並沒有很完美的解決方案。大多數系統設計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的併發請求落到底層存儲系統上。在數據魔方中，我們設計的緩存過期機制理論上能夠將各個客戶端的數據失效時間均勻地分佈在時間軸上，一定程度上能夠避免緩存同時失效帶來的雪崩效應。
2015年雙十一，阿里還是用的自研OceanBase數據庫1秒14萬單！阿里雲支撐“雙11”912.17億商業奇蹟
2015天貓雙11全球狂歡節再次刷新一系列世界紀錄。912.17億元的天量交易背後，是中國計算能力的登頂全球。11日，阿里巴巴集團披露，當天系統交易創建峯值達到每秒鐘14萬筆，支付峯值達到每秒鐘8.59萬筆。相比2009年首屆雙11，訂單創建峯值增長了350倍，支付峯值增長了430倍。
爲了支撐這一天量的高併發交易，阿里巴巴今年實現了多項世界級技術創新：全球最大規模混合雲架構；全球首個核心交易系統上雲；1000公里外交易支付“異地多活”；全球首個應用在金融業務的分佈式關係數據庫OceanBase。
“這些世界頂尖的技術，正在通過阿里雲加速向外輸出。我們希望將這些技術變成普惠科技，以此催生1萬個阿里巴巴”，阿里雲總裁胡曉明說。
全球最大規模混合雲架構實踐
胡曉明介紹，今年雙11淘寶天貓核心交易鏈條和支付寶核心支付鏈條的部分流量，直接切換到阿里雲的公共雲計算平臺上。通過將公共雲和專有云無縫連接的模式，全面支撐雙11。
因此，如果從技術層面來看，今年雙11成爲了一場全球最大規模的混合雲彈性架構實踐。阿里巴巴成爲全球大型互聯網公司中，首個將核心交易系統放在雲上的企業。阿里雲成爲全球第一家有能力支撐核心交易系統的雲服務商。
“將淘寶、天貓、支付寶這麼龐大、複雜、跟錢緊密關聯的系統搬到雲上，除了我們全世界還沒有第二家，這包括全球互聯網巨頭和雲計算公司。”胡曉明說，阿里巴巴希望在自身最重要商業實踐中，驗證雲計算的安全性、可靠性，向世界證明雲計算的優勢。
胡曉明強調：“這一混合雲架構完全基於阿里雲官網在售的標準化產品搭建的。也就是說，你通過這些標準化的產品，也可以搭建這樣一個像淘寶、天貓這樣萬億級的企業應用，滿足任何極端的業務挑戰。”
“在雙11中應用的關鍵技術都將變成阿里雲上的標準化產品向外輸出。”胡曉明說，我們希望把驗證過的技術儘快分享給全球的創新創業者。
據悉，經此次雙11驗證並計劃輸出的技術包括：應用於異地多活的數據傳輸產品DataTransmission、實時計算系統StreamSQL、數據可視化引擎dataV等。
全球首秀1000公里異地多活能力
如果阿里巴巴的數據中心出現故障會怎樣？“異地多活”正是爲了應對這一突發情況。通過“異地多活”技術，系統可以迅速的把流量全部切換到另外的數據中心。整個過程不會對業務造成任何影響，用戶也幾乎沒有感知。
據阿里巴巴技術保障部研究員畢玄介紹，早在去年“雙11”，阿里巴巴就已經實現了交易系統的“異地雙活”。和去年“雙活”相比，今年最大的變化有兩點：一是同時實現了交易和支付的“多活”；二是異地數據中心的最遠距離超過1000公里，這意味着阿里巴巴具備了在全國任意節點部署交易系統的能力。
“這就像爲1000公里外空中飛行的飛機更換引擎。不僅不能影響飛行，飛機上的乘客也不能有感覺。”畢玄表示，尤其在支付寶這樣高度複雜與嚴謹的金融系統中，實現1000公里以上的“異地多活”能力，在全球也絕無先例，完全顛覆了傳統金融的災備概念。
公開資料顯示，全球能夠做到異地多活的只有少數幾家互聯網巨頭如Google、Facebook，但無論是搜索還是社交場景，對數據同步性、一致性的要求遠不如電商場景苛刻。
中國自研數據庫支撐全球最強支付平臺
雙11當天，螞蟻金服旗下的支付寶平穩支撐起了8.59萬筆/秒的交易峯值，是去年雙十一峯值3.85萬筆/秒的2.23倍。
這一數字大幅超越了Visa和MasterCard的實際處理能力，甚至比二者的實驗室數據都要高出一大截。這意味着經歷了雙十一大考的中國支付系統，在技術上已大幅領先全球。
支撐支付寶實現這一超越的祕密武器，是阿里巴巴與螞蟻金服自主研發的分佈式關係數據庫Oceanbase。 OceanBase是中國首個具有自主知識產權的數據庫，也是全球首個應用在金融業務的分佈式關係數據庫。
螞蟻金服首席技術官程立介紹，今年雙11的核心交易流100%由金融級海量數據庫OceanBase承載。和常用的商業數據庫相比，OceanBase成本不到其一半。分佈式的系統可以更好地應對雙11這類大流量衝擊。
OceanBase 2010年誕生，2014年支撐了10%的雙11交易流量。今年6月，網商銀行開業，底層數據庫全部採用OceanBase，是第一家完全擺脫商業數據庫的金融機構。而PayPal等美國金融機構，仍然主要依靠Oracle等。
ODPS-StreamSQL：讓未來實時計算更順暢
開放數據處理服務(Open Data Processing Service， 簡稱ODPS)是由阿里雲自主研發，提供針對TB/PB級數據、實時性要求不高的分佈式處理能力，應用於數據分析、挖掘、商業智能等領域。阿里巴巴的離線數據業務都運行在ODPS上。其“海量運算””開箱即用”、“安全防護到位”、“按量付費”等特點，使得其保證了阿里雲用戶可以輕鬆實現大數據的順利運行，一勞永逸的解決數據煩惱。
今年雙11，淘寶、天貓、支付寶、菜鳥等所有大數據處理工作，都將由阿里雲ODPS來完成。在剛剛結束的2015世界Sort Benchmark排序比賽中，阿里雲ODPS用377秒完成了100TB的數據排序，打破了此前Apache Spark創造的1406秒紀錄，一舉創造4項世界紀錄。ODPS根據用戶實際的存儲和計算消耗收費，最大化的降低用戶的數據使用成本。目前，國內首家將核心系統放在雲上的基金公司-天弘基金與首家互聯網保險公司-衆安保險都是阿里雲ODPS的用戶。
ODPS的實時計算系統StreamSQL在今年的雙11技術支撐過程表現搶眼，據阿里內部對外宣佈，雙11當天通過StreamSQL系統，交易系統預計日消息處理量將達上萬億條。據瞭解，阿里雲StreamSQL系統是一款秒級實時流計算產品，用戶可以直接在SQL編程裏使用。在今年7月北京舉辦的“阿里雲分享日X雲棲大會”上，阿里雲資深總監李津正式發佈了這款產品，作爲分析型數據庫，它可以完成海量數據的實時多維分析，實現海量數據多維比對和碰撞。而這一產品在剛剛過去的雙11過程中得到了充分的檢驗，並且成績優異，而這一能力，正在通過阿里雲逐步開放出來。
dataV：讓數據分析也進入“讀圖”時代
在阿里巴巴每天海量的交易面前，如何精準把握由數據脈搏帶來的趨勢也成爲極大的挑戰。
對此，阿里巴巴自主研發了dataV數據可視化引擎，該引擎完全基於Web 技術 ，可快速、低成本的部署。用於內部的商品、交易、支付、數據中心等的可視化呈現和管理，幫助實現更精準的調控。
自2013年起，雙11交易數據大屏成爲對外直播狂歡節的重要窗口，而在2015年的全球狂歡節上，這一樹立在水立方的巨型數據大屏，以實時動態可視圖的方式向全球用戶直播了雙11的數據魅力。
據悉，水立方數據大屏上，該數據可視化引擎既可以利用3D webgl技術從宏觀角度展示雙十一平臺總體交易訂單實時流向的全量展示，也可以通過便捷的交互手段，深入到城市級別進行微觀的人羣畫像分析。
目前，這一技術已計劃通過阿里雲向外輸出，很快將會有標準化產品推出。
OceanBase：中國自研數據庫正式崛起
雙11當天，劉振飛在接受媒體採訪時的一段話觸動了很多人：“我上大學的時候，我的導師跟我說，中國有三個IT技術沒有辦法突破，一個是操作系統，第二是數據庫，第三是芯片，今天可以非常自豪地說，在阿里起碼把數據庫這個問題解決掉了，我們終於有了完全自主可控的數據庫。”
沒錯，五年前阿里巴巴就開始打造自主可控的數據庫產品OceanBase，2014年其支撐了10%的雙11交易流量，而今年雙11的核心交易流量，100%都由OceanBase來承載。很明顯，阿里這一舉動將對全球IT業的格局產生深遠影響。
由於對硬件設備能力和軟件許可的弱需求，通過OceanBase可以比採用傳統商業數據庫節約50%的成本。同時，分佈式的系統，可以更好地應對雙11這類大流量衝擊：彈性能力可保證大促之前完成一鍵擴容、大促之後實現一鍵縮容，並且性能方面已經完全符合金融級海量數據庫標準。
據阿里內部數據顯示，雙11當天，螞蟻金服旗下的支付寶平穩支撐起了8.59萬筆/秒的交易峯值，是去年雙十一峯值3.85萬筆/秒的2.23倍。這一數字大幅超越了Visa和MasterCard的實際處理能力，甚至比二者的實驗室數據都要高出一大截。這意味着經歷了雙十一大考的中國支付系統，在技術上已大幅領先全球。而後臺起到關鍵支撐作用的祕密武器就是 Oceanbase。
作爲中國首個具有自主知識產權的數據庫，也是全球首個應用在金融業務的分佈式關係數據庫。OceanBase計劃明年可以通過阿里雲的公共計算平臺對外界開放。