你們好，我是淘寶技術保障部的江楓。眼下主要負責數據庫的穩定性這一塊。雙十一這一天。我主要是負責協調整個數據庫團隊和保障整個數據庫在「雙十一」過程當中的穩定性不受不論什麼影響。html
那給咱們具體的談一下淘寶網現在整個數據庫整體的一個架構。包含它硬件的組成。
淘寶的數據庫發展到今天。已是一個很是複雜的系統。前端
我大概算了一下。淘寶眼下所有的數據庫服務器加起來可能已經超過800臺。數據庫
那在這麼一個規模底下，淘寶的數據庫團隊這麼多年也是隨着淘寶的業務發展一塊兒成長起來的。但淘寶數據庫眼下核心的數據庫還在小型機和高端的存儲上面，還有很是多的數據庫現在是用的是MySQL，咱們逐步在從Oracle到MySQL這個方向在轉移，因此咱們MySQL PC server硬件也是很是多的了。 咱們也瞭解到。現在淘寶的整個的數據庫團隊在逐漸的把一些數據庫從Oracle遷移到MySQL，而後呢。把一些服務器由小型機轉到PC server。那大家整個轉變的動機是什麼？
主要是因爲業務壓力給了咱們最大的動力。07年我來到淘寶的時候，當時僅僅有三個基本的數據庫，所有在小型機和存儲上面。以當時的壓力來看，它跑起來是很是順利的，而且你們也知道小型機它從Unix操做系統到硬件，穩定性都會比PC server事實上要高很是多，當時的狀況下淘寶用小型機是一個很是天然的選擇。緩存
從07年開始淘寶的業務量保持每一年天然翻一番的增加，數據庫質量感受到很是大的壓力。那麼前端業務量增加一倍。在數據庫上有可能增加是好幾倍，它有一個放大效應在裏邊。當時咱們第一步能夠想到很是天然的架構，就是把三個數據庫拆成不少其它的數據庫，或每一個數據庫支持一個比較單一的業務。比方用戶、商品和交易，都會分紅獨立的數據庫，而後放到獨立的小型計算中去，這是咱們08年作的很是大的事情就是垂直拆分，而後08年的業務咱們就頂住了。
當時咱們就預估09年、10年會有更大的壓力增加，這個時候咱們應該怎麼辦？當時咱們從業界能看到很是多的經驗分享，包含eBay、亞馬遜這些國外的大公司。他們的經驗分享裏面，水平拆分是咱們數據庫漲到必定程度後的架構選擇。咱們從Oracle到MySQL轉移，主要是用水平拆分，這是咱們將來的一個弱點。那水平拆分後機器、數據庫的數量都會多很是多，那Oracle它自己的成本也是咱們考慮的一個重要因素，因此當時從成本考慮的話，那個時候咱們天然會選擇用MySQL數據庫。給咱們再簡單總結一下這幾年，淘寶整個數據庫的演變過程？
剛纔說到08年咱們作完垂直拆分之後，09年到今年咱們主要作的工做事實上就是水平拆分。今年在十月份以前咱們所有完畢了淘寶最核心的三個系統：交易數據庫、商品數據庫和用戶數據庫的水平拆分。因此到「雙十一」以前，在咱們內部採訪中，我一直跟採訪人員說，當時數據庫情緒穩定。基本上咱們沒有作什麼事情，僅僅是在不停的看報表，看數據。而後很是開心的看到交易曲線以超過45度的趨勢往上漲。那前期仍是作了很是無缺的準備。服務器
據咱們瞭解在整個從小型機到PC server的遷移，包含從Oracle到MySQL數據庫的遷移，大家在作這個事情的時候。都作過好幾個月的壓力測試。你講講這個背景和故事。
是這樣的，今年咱們年初決定。咱們商品庫從小型機遷到PC server上面去，這是淘寶壓力最大的一個數據庫，當時是用四臺小型機加兩個高端存儲來支撐的。要把這麼大一個數據庫進行遷移。咱們內心面也是沒有底的，因爲不知道要多少臺PC server能夠支撐。需要什麼樣的配置來支撐這個壓力？當時咱們能夠想到一個很是直觀的想法就是模擬線上全然同樣的壓力。甚至加上幾倍的壓力來測它的極限值。
咱們和開發團隊、咱們的性能測試團隊，加上DBA團隊和ops團隊，成立了一個很是大的項目組，而後作了接近兩個月的性能測試，在整個測試過程當中發現了很是多的問題，包含咱們給Oracle、MySQL等廠商都提交了很是多Bug，有些Bug也獲得廠商迴應。進行修復。架構
那整體的轉變的過程到現在進行到了什麼樣的程度？包含你在整個轉變的過程當中遇到哪些問題？
咱們現在最核心的用戶數據庫今年已經完全完畢了從小型機、存儲和Oracle切入到PC server加MySQL的架構。
咱們內部有一個提法叫作去O、去I、去E。事實上就是咱們要從高端硬件Scale up模式到低端硬件的Scal out水平擴展的模式，這是淘寶內部最大最核心的系統。今年已經順利完畢了所有區的水平擴展。其它幾個系統，比方說交易和商品已經完畢了一部分，完畢了水平拆分的一部分，但是沒有達到咱們但願的進度。這多是明年咱們需要作的事情。併發
在轉型過程當中主要遇到哪些問題？
讓咱們認爲比較大的問題就是咱們從可靠的小型機遷移到大規模，大數據量的PC server上來，從架構上就對咱們就是一個很是大的挑戰。你們都知道。每一個PC server的穩定性確定和單臺小型機會有必定的差距。再加上咱們一個機羣有多是32臺或者64臺PC server。高併發
每一臺PC server即便有四個9的可用性。但假設咱們整個系統合在一塊兒。可能它最後的兩個9的可用性都達不到。性能
這就需要咱們從軟件層、架構層要作很是多的改進。能夠要讓單點的一些失效對整體的系統不形成不論什麼影響，因爲咱們和架構部門、開發部門一塊兒作了很是多事情，才幹保證咱們的集羣穩定上線。大數據
事實上「雙十一」這個時間應該說是對過去的技術轉變的檢驗，現在回頭來看，這個檢驗的結果怎麼樣？
當時是有點提心吊膽的，以後又認爲相對來講今年咱們作的很是多事情仍是很是成功的。但是現在再回頭細緻想一想仍是有點後怕，「雙十一」那天的凌晨零點不是有一次Ipad的秒殺嗎。當天晚上咱們都在線上觀察數據，在零點的一瞬間，就看到所有數據庫指標已經達到了曾經正常時候最高峯的指標，有些甚至還超過了。
當天晚上睡覺的時候內心就有點在打鼓：才零點就這個樣子了，明天下午明天晚上最高峯的時候咱們應該怎麼渡過？因此次日早上八點多的時候咱們一進到指揮部裏面就看到所有的指標， 包含CDN的指標、各個業務線的指標、數據庫的指標都是噌噌的往上漲，這時內心面事實上是很是忐忑不安的。
但是咱們比較放心的是這三大核心繫統，商品、用戶和交易，在咱們今年所有的水平擴展項目作完了之後，比方說商品功能作完了之後。從咱們的機械壓測裏面它是有十倍的流量的，因此當天百分之中的一個百，百分之兩百的流量基本上對數據庫沒有形成太大的影響，因此當時仍是很是開心的看到這個指標高速的往上漲，但願交易能夠經過10個億、20個億，我認爲都是能夠承受的。那對於整個數據庫架構的演進下一步有什麼打算？
下一步事實上就是剛剛說的咱們有幾個核心系統尚未全然的作到這個水平擴展，加上「雙十一」那天咱們仍是有一個小驚險：咱們有一個數據庫，跟交易核心有一點點聯繫的，但它仍是放在小型機上面。當時已經提早爲它準備了百分之中的一個百的餘量，就是說它能夠承擔平時最高壓力的兩倍。
但是那天已經達到平時最高壓力的1.8倍左右的時候，把咱們嚇出了一身冷汗。假設當時淘寶的交易最高峯的流量再增加20%的話，有可能數據庫就會到瓶頸了。
因此咱們明年是要把不少其它這樣的Scale up能夠看到天花板的數據庫所有要拆分紅水平庫存這樣的數據庫。那你剛纔所提到的去Oracle，去小型機。去高端存儲，這個「三去」的整體思路給淘寶網帶來了哪些經濟上的效應？
當時咱們知道小型機和存儲的價格是很是昂貴的，仍是拿咱們剛纔說壓力最大的商品數據庫舉個樣例，當初咱們數據庫是用了四臺高端的小型機。兩套高端的存儲，成本加起來起碼都是三千萬以上。
那眼下咱們用的是32臺PC server來搭建的一個機羣，價格也就是300萬~500萬的級別。相對來講咱們作完這個事情之後。攻克了兩三千萬的硬件成本。這樣來說。整體的經濟效益仍是很是不錯的。但是事實上剛纔咱們在前期溝通的時候也提到，你要從Oracle轉到MySQL，包含從小型機轉到PC server。事實上裏面仍是會遇到蠻多問題的，包含它的不穩定性等等。那對於這一方面你有沒有什麼經驗可談？
在這一方面，我認爲有兩個很是重要的因素。第一個是咱們需要和咱們的開發前端應用架構部門能夠緊密的合做，可讓咱們的應用融入剛纔說的整個機羣的單點失效和容災的問題。
都需要咱們和架構部門一塊兒來考慮的；第二個比較大的經驗就是眼下咱們在作的。深刻研究MySQL的源碼。咱們從研究和壓力測試的過程當中。發現MySQL它自己代碼的一些缺陷。可能在高併發大壓力下會有很是多隱藏的Bug。
在咱們近期的此次測試其中。咱們還發現了Facebook公佈的FlashCache二級緩存的軟件。當時咱們是測出它一個很是大的Bug：併發壓力很是大的狀況下，它會致使MySQL成爲一個殭屍進程。
咱們發現了之後。很是快反饋給Face book，而後Face book很是快就修復了這個問題，這也是咱們對使用開源軟件帶來更大的一個信心，就是開源能夠在全球獲得不少其它的支持，你們均可以從原代碼層面來解決更深層次的一個問題。我想這也多是淘寶技術團隊現在那麼開放，那麼注重開源的動力之中的一個。那假設說想對MySQL的一些核心代碼作編譯，就需要對人才的儲備，包含各方面資源整合的要求仍是蠻大的，那你在這方面有沒有什麼感觸？
說到人才這個話題。08年的時候，淘寶當時準備大規模的往MySQL方向上轉。咱們內部也是有一些置疑的聲音。他們說淘寶DDA團隊曾經都是在Oracle方面比較專精，在業界來講，淘寶的DDA團隊在Oracle方面更加有名氣一些。因此咱們內部有置疑的聲音。就是說大家有MySQL專家嗎，MySQL出問題了之後能很是快的解決嗎？因此從08年到現在，咱們慢慢的一路走過來，內部培養了很是多的MySQL的人才，包含這幾年咱們的應屆生的成長。再加上咱們從外部招到一些專家，咱們對MySQL的理解已經愈來愈深。
剛纔說到，咱們已經能夠給MySQL打Patch。已經能夠給MySQL report這些Bug。到現在爲止。我認爲MySQL的成長已經達到了很是高的一個程度。咱們對MySQL已經愈來愈有信心，但是將來淘寶的MySQL確定是要作得愈來愈大的，淘寶還有很是多小型機上面擴展不太easy的系統需要遷移到可擴展的機羣上面來，但咱們也但願業界能夠有不少其它的MySQL夥伴增長咱們。和咱們一塊兒來作這麼一件很是有意義的事情。我想能夠增長到淘寶的技術團隊，去經歷那麼多有大交易量的技術實踐仍是很是寶貴的。另一個問題就是儘管說現在咱們用的愈來愈多的是MySQL。但是現在你們也知道MySQL已經被Oracle收購了，那對像淘寶這樣的團隊有什麼影響呢？
你們都知道MySQL事實上是基於GPL的協議來開源的軟件，那淘寶在使用過程當中，前期是已經考慮到一些風險。因此咱們所有的MySQL都是本身來作編譯作優化的，而且我想MySQL被Oracle收購了之後。現在看起來Oracle應該是給MySQL在開發這方面是提供了更大的幫助，像以前在Sun的時候，MySQL的版本號相對來講是比較混亂的，包含咱們現在在用的5.0和5.1的正式版本號，近期還有包含開發方面就還有兩個。一個6.0，一個5.4。這些特性會互相交織在一塊兒，讓咱們選擇的時候也有點不知道究竟選哪一個版本號會更好一點。
但現在Oracle收購MySQL之後，他把5.4跟6.0這些版本號已經合成了一個比較規範的5.5的版本號，而且爲它制訂了很是好的一個milestone15：31，將來要怎麼發展這個里程碑，M一、M二、M三、M4這樣的發展方向。而到現在爲止這個5.5已經發展到5.六、5.7的版本號，而且已是IC版本號了，很是快就要GA了，那我想這對於MySQL來講應該是一個好消息。咱們能夠用到不少其它更穩定的新特性。 5.5版本號裏有幾個新的特性是咱們很是關注的，比方Google已經達到英文15：57這個pach。因此咱們認爲對咱們將來的這個MySQL這個系統很是實用的一個功能。那咱們也等着Oracle的5.5這個版本號能夠儘快的GA出來。