上一篇淺談淘寶技術(shù)發(fā)展：Java時(shí)代——脫胎換骨中提到去IOE這一部分，已經(jīng)有讀者在迫不及待的問怎么去掉了IOE，別急，在去掉IOE之前還有很長的路要走。行癲他們買回來小型機(jī)之后，我們用上了Oracle，七公帶著一幫DBA在優(yōu)化SQL和存儲(chǔ)，行癲帶著幾個(gè)架構(gòu)師在研究數(shù)據(jù)庫的擴(kuò)展性。Oracle本身是一個(gè)封閉的系統(tǒng)，用Oracle怎么做擴(kuò)展？用現(xiàn)在一個(gè)時(shí)髦的說法就是做“分庫分表”。

我們知道一臺(tái)Oracle的處理能力是有上限的，它的連接池有數(shù)量限制，查詢速度跟容量成反比。簡單的說，在數(shù)據(jù)量上億、查詢量上億的時(shí)候，就到它的極限了。要突破這種極限，最簡單的方式就是多用幾個(gè)Oracle數(shù)據(jù)庫。但一個(gè)封閉的系統(tǒng)做擴(kuò)展，不像分布式系統(tǒng)那樣輕松。我們把用戶的信息按照ID來放到兩個(gè)數(shù)據(jù)庫里面（DB1/DB2），把商品的信息跟著賣家放在兩個(gè)對應(yīng)的數(shù)據(jù)庫里面，把商品類目等通用信息放在第三個(gè)庫里面(DBcommon)。這么做的目的除了增加了數(shù)據(jù)庫的容量之外，還有一個(gè)就是做容災(zāi)，萬一一個(gè)數(shù)據(jù)庫掛了，整個(gè)網(wǎng)站上還有一半的數(shù)據(jù)能操作。

數(shù)據(jù)庫這么分了之后，應(yīng)用程序有麻煩了，如果我是一個(gè)買家，買的商品有DB1的也有DB2的，要查看“我已買到的寶貝”的時(shí)候，應(yīng)用程序怎么辦？必須到兩個(gè)數(shù)據(jù)庫里面分別查詢出來對應(yīng)的商品。要按時(shí)間排序怎么辦？兩個(gè)庫里面“我已買到的寶貝”全部查出來在應(yīng)用程序里面做合并。還有分頁怎么處理？關(guān)鍵字查詢怎么處理？這些東西交給程序員來做的話會(huì)很悲催，于是行癲在淘寶的***個(gè)架構(gòu)上的作品就來解決了這個(gè)問題，他寫了一個(gè)數(shù)據(jù)庫路由的框架DBRoute，這個(gè)框架在淘寶的Oracle時(shí)代一直在使用。后來隨著業(yè)務(wù)的發(fā)展，這種分庫的第二個(gè)目的——容災(zāi)的效果就沒有達(dá)到。像評價(jià)、投訴、舉報(bào)、收藏、我的淘寶等很多地方，都必須同時(shí)連接DB1和DB2，哪個(gè)庫掛了都會(huì)導(dǎo)致整個(gè)網(wǎng)站掛掉。

上一篇說過，采用EJB其實(shí)是和Sun的工程師妥協(xié)的結(jié)果，在他們走了之后，EJB也逐漸被冷落了下來。在05、06年的時(shí)候，spring大放異彩，正好利用spring的反射（IoC）模式替代了EJB的工廠模式，給整個(gè)系統(tǒng)精簡了很多代碼。

上一篇還說過，為了減少數(shù)據(jù)庫的壓力，提高搜索的效率，我們引入了搜索引擎。隨著數(shù)據(jù)量的繼續(xù)增長，到了2005年，商品數(shù)有1663萬，PV有8931萬，注冊會(huì)員有1390萬，這給數(shù)據(jù)和存儲(chǔ)帶來的壓力依然山大，數(shù)據(jù)量大，性能就慢。親，還有什么辦法能提升系統(tǒng)的性能？一定還有招數(shù)可以用，這就是緩存和CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）。

你可以想象，九千萬的訪問量，有多少是在商品詳情頁面？訪問這個(gè)頁面的時(shí)候，數(shù)據(jù)全都是只讀的（全部從數(shù)據(jù)庫里面讀出來，不寫入數(shù)據(jù)庫），如果把這些讀操作從數(shù)據(jù)庫里面移到內(nèi)存里，數(shù)據(jù)庫將會(huì)多么的感激涕零。在那個(gè)時(shí)候我們的架構(gòu)師多隆大神，找到了一個(gè)基于 Berkeley DB 的開源的緩存系統(tǒng)，把很多不太變動(dòng)的只讀信息放了進(jìn)去。其實(shí)最初這個(gè)緩存系統(tǒng)還比較弱，我們并沒有把整個(gè)商品詳情都放在里面，一開始把賣家的信息放里面，然后把商品屬性放里面，商品詳情這個(gè)字段太大，放進(jìn)去受不了。說到商品詳情，這個(gè)字段比較恐怖，有人統(tǒng)計(jì)過，淘寶商品詳情打印出來平均有5米長，在系統(tǒng)里面其實(shí)放在哪里都不招人待見。筆者清楚的記得，我來淘寶之后擔(dān)任項(xiàng)目經(jīng)理做的***個(gè)項(xiàng)目就是把商品詳情從商品表里面給移出來。這個(gè)字段太大了，查詢商品信息的時(shí)候很多都不需要查看詳情，它跟商品的價(jià)格、運(yùn)費(fèi)這些放在一個(gè)表里面，拖慢了整個(gè)表的查詢速度。在05年的時(shí)候，我把商品詳情放在數(shù)據(jù)庫的另外一張表里面，再往后這個(gè)大字段被從數(shù)據(jù)庫里面請了出來，這也讓數(shù)據(jù)庫再一次感激涕零。

到現(xiàn)在為止，整個(gè)商品詳情的頁面都在緩存里面了，眼尖的讀者可能會(huì)發(fā)現(xiàn)現(xiàn)在的商品詳情不全是“只讀”的信息了，這個(gè)頁面上有個(gè)信息叫“瀏覽量”，這個(gè)數(shù)字每刷新一次頁面就要“寫入”數(shù)據(jù)庫一次，這種高頻度實(shí)時(shí)更新的數(shù)據(jù)能用緩存嗎？如果不用緩存，一天幾十億的寫入，數(shù)據(jù)庫會(huì)怎么樣？一定會(huì)掛掉。那怎么辦？親……先不回答你（下圖不是廣告，讓你看看瀏覽量這個(gè)數(shù)據(jù)在哪里）。

CDN這個(gè)工作相對比較獨(dú)立，跟別的系統(tǒng)一樣，一開始我們也是采用的商用系統(tǒng)。后來隨著流量的增加，商用的系統(tǒng)已經(jīng)撐不住了，LVS的創(chuàng)始人章文嵩博士帶人搭建了淘寶自己的CDN網(wǎng)絡(luò)。在本文的引言中我說過淘寶的CDN系統(tǒng)支撐了800Gbps以上的流量，作為對比我們可以看一下國內(nèi)專業(yè)做CDN的上市公司ChinaCache的介紹——“ChinaCache……是中國***的專業(yè)CDN服務(wù)提供商，向客戶提供全方位網(wǎng)絡(luò)內(nèi)容快速分布解決方案。作為首家獲信產(chǎn)部許可的CDN服務(wù)提供商，目前ChinaCache在全國50多個(gè)大中城市擁有近300個(gè)節(jié)點(diǎn)，全網(wǎng)處理能力超過500Gbps，其CDN網(wǎng)絡(luò)覆蓋中國電信、中國網(wǎng)通、中國移動(dòng)、中國聯(lián)通、中國鐵通和中國教育科研網(wǎng)等各大運(yùn)營商。”——這樣你可以看得出淘寶在CDN上面的實(shí)力，這在全世界都是數(shù)一數(shù)二的。另外因?yàn)镃DN需要大量的服務(wù)器，要消耗很多能源（消耗多少？在前兩年我們算過一筆帳，淘寶上產(chǎn)生一個(gè)交易，消耗的電足以煮熟4個(gè)雞蛋）。這兩年章文嵩的團(tuán)隊(duì)又在研究低功耗的服務(wù)器，在綠色計(jì)算領(lǐng)域也做了很多開創(chuàng)性的工作。淘寶CDN的發(fā)展需要專門一個(gè)章節(jié)來講，想先睹為快的可以看一下筆者對章文嵩的專訪：http://qing.weibo.com/1866752224/6f4460e033000jme.html

回想起剛用緩存那段時(shí)間，筆者還是個(gè)小菜鳥，有一個(gè)經(jīng)典的錯(cuò)誤常常犯，就是數(shù)據(jù)庫的內(nèi)容更新的時(shí)候，忘記通知緩存系統(tǒng)，結(jié)果在測試的時(shí)候就發(fā)現(xiàn)我改過的數(shù)據(jù)怎么在頁面上沒變化呢。后來做了一些頁面上的代碼，修改CSS和JS的時(shí)候，用戶本地緩存的信息沒有更新，頁面上也會(huì)亂掉，在論壇上被人說的時(shí)候，我告訴他用ctrl+F5刷新頁面，然后趕緊修改腳本文件的名稱，重新發(fā)布頁面。學(xué)會(huì)用ctrl+F5的會(huì)員對我佩服的五體投地，我卻慚愧的無地自容。

有些技術(shù)的發(fā)展是順其自然的，有些卻是突如其來的。到2007年的時(shí)候，我們已經(jīng)有幾百臺(tái)應(yīng)用服務(wù)器了，這上面的java應(yīng)用服務(wù)器是weblogic，而weblogic是非常貴的，比這些服務(wù)器本身都貴。有一段時(shí)間多隆研究了一下jboss，說我們換掉weblogic吧，于是又省下了不少銀兩。那一年，老馬舉辦了***屆的“網(wǎng)俠大會(huì)”，會(huì)上來的大俠中有一位是上文提到的章文嵩，還有一位曾經(jīng)在jboss團(tuán)隊(duì)工作，我們也把這位大俠留下了，這樣我們用起jboss更加有底氣了。

這些雜七雜八的修改，我們對數(shù)據(jù)分庫、放棄EJB、引入Spring、加入緩存、加入CDN、采用開源的Jboss，看起來沒有章法可循，其實(shí)都是圍繞著提高容量、提高性能、節(jié)約成本來做的，由于這些不算大的版本變遷，我們姑且叫它2.1版吧，這個(gè)版本從構(gòu)圖上來看有3只腳，是不是穩(wěn)定了很多？

架構(gòu)圖如下：

下集預(yù)告：創(chuàng)造技術(shù) 分布式文件系統(tǒng)TFS、分布式kv緩存tair、搜索引擎升級