江楓先給咱們介紹一下本身，和你在此次淘寶「雙十一」事件中所扮演的角色？ 前端
你們好，我是淘寶技術保障部的江楓。目前主要負責數據庫的穩定性這一塊。雙十一這一天，我主要是負責協調整個數據庫團隊和保障整個數據庫在「雙十一」過程當中的穩定性不受任何影響。數據庫
那給咱們詳細的談一下淘寶網如今整個數據庫總體的一個架構，包括它硬件的組成。 緩存
淘寶的數據庫發展到今天，已是一個很是複雜的系統。我大概算了一下，淘寶目前全部的數據庫服務器加起來可能已經超過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確定是要作得愈來愈大的，淘寶還有不少小型機上面擴展不太容易的系統須要遷移到可擴展的機羣上面來，但咱們也但願業界可以有更多的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出來。
