轉自：http://blog.sina.com.cn/s/blog_633219970100ybfx.html
淘寶技術發展（Java時代：堅若磐石）
我們知道一臺Oracle的處理能力是有上限的，它的連接池有數量限制，查詢速度跟容量成反比。簡單的說，在數據量上億、查詢量上億的時候，就到它的極限了。要突破這種極限，最簡單的方式就是多用幾個Oracle數據庫。但一個封閉的系統做擴展，不像分佈式系統那樣輕鬆。我們把用戶的信息按照ID來放到兩個數據庫裏面（DB1/DB2），把商品的信息跟着賣家放在兩個對應的數據庫裏面，把商品類目等通用信息放在第三個庫裏面(DBcommon)。這麼做的目的除了增加了數據庫的容量之外，還有一個就是做容災，萬一一個數據庫掛了，整個網站上還有一半的數據能操作。
數據庫這麼分了之後，應用程序有麻煩了，如果我是一個買家，買的商品有DB1的也有DB2的，要查看“我已買到的寶貝”的時候，應用程序怎麼辦？必須到兩個數據庫裏面分別查詢出來對應的商品。要按時間排序怎麼辦？兩個庫裏面“我已買到的寶貝”全部查出來在應用程序裏面做合併。還有分頁怎麼處理？關鍵字查詢怎麼處理？這些東西交給程序員來做的話會很悲催，於是行癲在淘寶的第一個架構上的作品就來解決了這個問題，他寫了一個數據庫路由的框架DBRoute，這個框架在淘寶的Oracle時代一直在使用。後來隨着業務的發展，這種分庫的第二個目的——容災的效果就沒有達到。像評價、投訴、舉報、收藏、我的淘寶等很多地方，都必須同時連接DB1和DB2，哪個庫掛了都會導致整個網站掛掉。
上一篇說過，採用EJB其實是和Sun的工程師妥協的結果，在他們走了之後，EJB也逐漸被冷落了下來。在05、06年的時候，spring大放異彩，正好利用spring的反射（IoC）模式替代了EJB的工廠模式，給整個系統精簡了很多代碼。
上一篇還說過，爲了減少數據庫的壓力，提高搜索的效率，我們引入了搜索引擎。隨着數據量的繼續增長，到了2005年，商品數有1663萬，PV有8931萬，註冊會員有1390萬，這給數據和存儲帶來的壓力依然山大，數據量大，性能就慢。親，還有什麼辦法能提升系統的性能？一定還有招數可以用，這就是緩存和CDN（內容分發網絡）。
你可以想象，九千萬的訪問量，有多少是在商品詳情頁面？訪問這個頁面的時候，數據全都是隻讀的（全部從數據庫裏面讀出來，不寫入數據庫），如果把這些讀操作從數據庫裏面移到內存裏，數據庫將會多麼的感激涕零。在那個時候我們的架構師多隆大神，找到了一個基於 Berkeley DB 的開源的緩存系統，把很多不太變動的只讀信息放了進去。其實最初這個緩存系統還比較弱，我們並沒有把整個商品詳情都放在裏面，一開始把賣家的信息放裏面，然後把商品屬性放裏面，商品詳情這個字段太大，放進去受不了。說到商品詳情，這個字段比較恐怖，有人統計過，淘寶商品詳情打印出來平均有5米長，在系統裏面其實放在哪裏都不招人待見。筆者清楚的記得，我來淘寶之後擔任項目經理做的第一個項目就是把商品詳情從商品表裏面給移出來。這個字段太大了，查詢商品信息的時候很多都不需要查看詳情，它跟商品的價格、運費這些放在一個表裏面，拖慢了整個表的查詢速度。在05年的時候，我把商品詳情放在數據庫的另外一張表裏面，再往後這個大字段被從數據庫裏面請了出來，這也讓數據庫再一次感激涕零。
到現在爲止，整個商品詳情的頁面都在緩存裏面了，眼尖的讀者可能會發現現在的商品詳情不全是“只讀”的信息了，這個頁面上有個信息叫“瀏覽量”，這個數字每刷新一次頁面就要“寫入”數據庫一次，這種高頻度實時更新的數據能用緩存嗎？如果不用緩存，一天幾十億的寫入，數據庫會怎麼樣？一定會掛掉。那怎麼辦？親……先不回答你（下圖不是廣告，讓你看看瀏覽量這個數據在哪裏）
CDN這個工作相對比較獨立，跟別的系統一樣，一開始我們也是採用的商用系統。後來隨着流量的增加，商用的系統已經撐不住了，LVS的創始人章文嵩博士帶人搭建了淘寶自己的CDN網絡。在本文的引言中我說過淘寶的CDN系統支撐了800Gbps以上的流量，作爲對比我們可以看一下國內專業做CDN的上市公司ChinaCache的介紹——“ChinaCache……是中國第一的專業CDN服務提供商，向客戶提供全方位網絡內容快速分佈解決方案。作爲首家獲信產部許可的CDN服務提供商，目前ChinaCache在全國50多個大中城市擁有近300個節點，全網處理能力超過500Gbps，其CDN網絡覆蓋中國電信、中國網通、中國移動、中國聯通、中國鐵通和中國教育科研網等各大運營商。”——這樣你可以看得出淘寶在CDN上面的實力，這在全世界都是數一數二的。另外因爲CDN需要大量的服務器，要消耗很多能源（消耗多少？在前兩年我們算過一筆帳，淘寶上產生一個交易，消耗的電足以煮熟4個雞蛋）。這兩年章文嵩的團隊又在研究低功耗的服務器，在綠色計算領域也做了很多開創性的工作。淘寶CDN的發展需要專門一個章節來講，想先睹爲快的可以看一下筆者對章文嵩的專訪：http://qing.weibo.com/1866752224/6f4460e033000jme.html
回想起剛用緩存那段時間，筆者還是個小菜鳥，有一個經典的錯誤常常犯，就是數據庫的內容更新的時候，忘記通知緩存系統，結果在測試的時候就發現我改過的數據怎麼在頁面上沒變化呢。後來做了一些頁面上的代碼，修改CSS和JS的時候，用戶本地緩存的信息沒有更新，頁面上也會亂掉，在論壇上被人說的時候，我告訴他用ctrl+F5刷新頁面，然後趕緊修改腳本文件的名稱，重新發布頁面。學會用ctrl+F5的會員對我佩服的五體投地，我卻慚愧的無地自容。
有些技術的發展是順其自然的，有些卻是突如其來的。到2007年的時候，我們已經有幾百臺應用服務器了，這上面的java應用服務器是weblogic，而weblogic是非常貴的，比這些服務器本身都貴。有一段時間多隆研究了一下jboss，說我們換掉weblogic吧，於是又省下了不少銀兩。那一年，老馬舉辦了第一屆的“網俠大會”，會上來的大俠中有一位是上文提到的章文嵩，還有一位曾經在jboss團隊工作，我們也把這位大俠留下了，這樣我們用起jboss更加有底氣了。
這些雜七雜八的修改，我們對數據分庫、放棄EJB、引入Spring、加入緩存、加入CDN、採用開源的Jboss，看起來沒有章法可循，其實都是圍繞着提高容量、提高性能、節約成本來做的，由於這些不算大的版本變遷，我們姑且叫它2.1版吧，這個版本從構圖上來看有3只腳，是不是穩定了很多？
架構圖如下：
下集預告：創造技術 分佈式文件系統TFS、分佈式kv緩存tair、搜索引擎升級