已經(jīng)有讀者在火燒眉毛的問怎么去失蹤了IOE，別急，在去失蹤IOE之前還有很長的路要走。行癲他們買回來小型機之后，我們用上了Oracle，七公帶著一幫DBA在優(yōu)化SQL和存儲，行癲帶著幾個架構(gòu)師在研究數(shù)據(jù)庫的擴展性。Oracle自己是一個封鎖的系統(tǒng)，用Oracle怎么做擴展?用此刻一個時髦的說法就是做“分庫分表”。
我們知道一臺Oracle的措置能力是有上限的，它的毗連池稀有目限制，發(fā)芽速度跟容量成反比。簡單的說，在數(shù)據(jù)量上億、發(fā)芽量上億的時辰，就到它的極限了。沖要破這種極限，最簡單的體例就是多用幾個Oracle數(shù)據(jù)庫。但一個封鎖的系統(tǒng)做擴展，不像分布式系統(tǒng)那樣輕松。我們把用戶的信息按照ID來放到兩個數(shù)據(jù)庫瑯縵沔(DB1/DB2)，把商品的信息跟著賣家放在兩個對應(yīng)的數(shù)據(jù)庫瑯縵沔，把商品類目等通用信息放在第三個庫瑯縵沔(DBcommon)。這么做的目的除了增添了數(shù)據(jù)庫的容量之外，還有一個就是做容災(zāi)，萬一一個數(shù)據(jù)庫掛了，整個網(wǎng)站上還有一半的數(shù)據(jù)能操作。
數(shù)據(jù)庫這么分了之后，應(yīng)用軌范有麻煩了，如不美觀我是一個買家，買的商品有DB1的也有DB2的，要查看“我已買到的寶物”的時辰，應(yīng)用軌范怎么辦?必需到兩個數(shù)據(jù)庫瑯縵沔分袂發(fā)芽出來對應(yīng)的商品。要按時刻排序怎么辦?兩個庫瑯縵沔“我已買到的寶物”全數(shù)查出來在應(yīng)用軌范瑯縵沔做合并。還有分頁怎么措置?關(guān)頭字發(fā)芽怎么措置?這些工具交給軌范員來做的話會很悲催，于是行癲在淘寶的第一個架構(gòu)上的作品就來解決了這個問題，他寫了一個數(shù)據(jù)庫路由的框架DBRoute，這個框架在淘寶的Oracle時代一向在使用。后來跟著營業(yè)的成長，這種分庫的第二個目的——容災(zāi)的效不美觀就沒有達(dá)到。像評價、投訴、舉報、保藏、我的淘寶等良多處所，都必需同時毗連DB1和DB2，哪個庫掛了城市導(dǎo)致整個網(wǎng)站掛失蹤。
上一篇說過，采用EJB其實是和Sun的工程師妥協(xié)的結(jié)不美觀，在他們走了之后，EJB也逐漸被蕭瑟了下來。在05、06年的時辰，spring年夜放異彩，正好操作spring的反射(IoC)模式替代了EJB的工場模式，給整個系統(tǒng)精簡了良多代碼。
上一篇還說過，為了削減數(shù)據(jù)庫的壓力，提高搜索的效率，我們?nèi)侨肆怂阉饕妗８鴶?shù)據(jù)量的繼續(xù)增添，到了2005年，商品數(shù)有1663萬，PV有8931萬，注冊會員有1390萬，這給數(shù)據(jù)和存儲帶來的壓力依然山年夜，數(shù)據(jù)量年夜，機能就慢。親，還有什么法子能晉升系統(tǒng)的機能?必然還有招數(shù)可以用，這就是緩存和CDN(內(nèi)容分發(fā)收集)。
你可以想象，九萬萬的訪謁量，有若干好多是在商品詳情頁面?訪謁這個頁面的時辰，數(shù)據(jù)全都是只讀的(全數(shù)年夜數(shù)據(jù)庫瑯縵沔讀出來，不寫入數(shù)據(jù)庫)，如不美觀把這些讀操作年夜數(shù)據(jù)庫瑯縵沔移到內(nèi)存里，數(shù)據(jù)庫將會何等的感謝感動涕零。在阿誰時辰我們的架構(gòu)師多隆年夜神，找到了一個基于 Berkeley DB 的開源的緩存系統(tǒng)，把良多不太變換的只讀信息放了進(jìn)去。頗晡差初這個緩存系統(tǒng)還斗勁弱，我們并沒有把整個商品詳情都放在瑯縵沔，一路頭把賣家的信息放瑯縵沔，然后把商品屬性放瑯縵沔，商品詳情這個字段太年夜，放進(jìn)去受不了。說到商品詳情，這個字段斗勁恐怖，有人統(tǒng)計過，淘寶商品詳情打印出來平均有5米長，在系統(tǒng)瑯縵沔其實放在哪里都不招人待見。筆者清囂張的記得，我來淘寶之后擔(dān)任項目司理做的第一個項目就是把商品詳情年夜商品內(nèi)外面給移出來。這個字段太年夜了，發(fā)芽商品信息的時辰良多都不需要查看詳情，它跟商品的價錢、運費這些放在一個內(nèi)外面，拖慢了整個表的發(fā)芽速度。在05年的時辰，我把商品詳情放在數(shù)據(jù)庫的此外一張內(nèi)外面，再往后這個年夜字段被年夜數(shù)據(jù)庫瑯縵沔請了出來，這也讓數(shù)據(jù)庫再一次感謝感動涕零。
到此刻為止，整個商品詳情的頁面都在緩存瑯縵沔了，眼尖的讀者可能會發(fā)現(xiàn)此刻的商品詳情不全是“只讀”的信息了，這個頁面上有個信息叫“瀏覽量”，這個數(shù)字每刷新一次頁面就要“寫入”數(shù)據(jù)庫一次，這種高頻度實時更新的數(shù)據(jù)能用緩存嗎?如不美觀不用緩存，一天幾十億的寫入，數(shù)據(jù)庫會怎么樣?必然會掛失蹤。那怎么辦?親……先不回覆你(下圖不是廣告，讓你看看瀏覽量這個數(shù)據(jù)在哪里)
CDN這個工作相對斗勁自力，跟此外系統(tǒng)一樣，一路頭我們也是采用的商用系統(tǒng)。后來跟著流量的增添，商用的系統(tǒng)已經(jīng)撐不住了，LVS的創(chuàng)始人章文嵩博士帶人搭建了淘寶自己的CDN收集。在本文的引言中我說過淘寶的CDN系統(tǒng)支撐了800Gbps以上的流量，作為對比我們可以看一下國內(nèi)專業(yè)做CDN的上市公司ChinaCache的介紹——“ChinaCache……是中國第一的專業(yè)CDN處事供給商，向客戶供給全方位收集內(nèi)容快速分布解決方案。作為首家獲信產(chǎn)部許可的CDN處事供給商，今朝ChinaCache在全國50多個年夜中城市擁有近300個節(jié)點，全網(wǎng)措置能力跨越500Gbps，其CDN收集籠蓋中國電信、中國網(wǎng)通、中國移動、中國聯(lián)通、中國鐵通和中國教育科研網(wǎng)等各年夜運營商。”——這樣你可以看得出淘寶在CDN膳縵沔的實力，這在全世界都是數(shù)一數(shù)二的。此外因為CDN需要年夜量的處事器，要耗損良多能源(耗損若干好多?在前兩年我們算過一筆帳，淘寶上發(fā)生一蓋氚摻，耗損的電足以煮熟4個雞蛋)。這兩年章文嵩的團隊又在研究低功耗的處事器，在綠色計較規(guī)模也做了良多開創(chuàng)性的工作。淘寶CDN的成長需要專門一個章節(jié)來講，想先睹為快的可以看一下筆者對章文嵩的專訪：http://qing.weibo.com/1866752224/6f4460e033000jme.html
回憶起剛用緩存那段時刻，筆者仍是個小菜鳥，有一個經(jīng)典的錯誤經(jīng)常犯，就是數(shù)據(jù)庫的內(nèi)容更新的時辰，健忘通知緩存系統(tǒng)，結(jié)不美觀在測試的時辰就發(fā)現(xiàn)我悔改的數(shù)據(jù)怎么在頁面膳縵慊轉(zhuǎn)變呢。后來做了一些頁面上的代碼，改削CSS和JS的時辰，用戶當(dāng)?shù)鼐彺娴男畔]有更新，頁面上也會亂失蹤，在論壇上被人說的時辰，我告訴他用ctrl+F5刷新頁面，然后趕緊改削劇本文件的名稱，年夜頭發(fā)布頁面。學(xué)會用ctrl+F5的會員對我服氣的五體投地，我卻忸捏的愧汗怍人。
有些手藝的成長是順其自然的，有些卻是突如其來的。到2007年的時辰，我們已經(jīng)有幾百臺應(yīng)用處事器了，這膳縵沔的java應(yīng)用處事器是weblogic，而weblogic長短常貴的，比這些處事器自己都貴。有一段時刻多隆研究了一下jboss，說我們換失蹤weblogic吧，于是又省下了不少銀兩。那一年，老馬舉辦了第一屆的“網(wǎng)俠年夜會”，會上來的年夜俠中有一位是上文提到的章文嵩，還有一位曾經(jīng)在jboss團隊工作，我們也把這位年夜俠留下了，這樣我們用起jboss加倍有底氣了。
推薦閱讀
跟著互聯(lián)網(wǎng)的不竭成長，此刻的互聯(lián)網(wǎng)已經(jīng)不是昔時那種少數(shù)人競爭的行業(yè)了，此刻良多網(wǎng)平易近也涌入了互聯(lián)網(wǎng)當(dāng)一名站長，于是互聯(lián)網(wǎng)成為了競爭激烈的行業(yè)，在這激烈的競爭之中良多站長卻忽略了用戶的益處，片面追求網(wǎng)>>>詳細(xì)閱讀
本文標(biāo)題：<b>淘寶網(wǎng)技術(shù)發(fā)展回顧（五） Java時代：堅若磐石</b>
地址：http://www.zcgs360.cn/a/22/20120401/47382.html
網(wǎng)友點評
精彩導(dǎo)讀
科技快報
品牌展示