淘寶技術發展（Java時代：堅若磐石）

        一、引言

        二、個人網站

        三、Oracle/支付寶/旺旺

        四、淘寶技術發展（Java 時代：脫胎換骨）

        已經有讀者在迫不及待的問怎么去掉了 IOE，別急，在去掉 IOE 之前還有很長的路要走。行癲他們買回來小型機之后，我們用上了 Oracle，七公帶著一幫 DBA 在優化 SQL 和存儲，行癲帶著幾個架構師在研究數據庫的擴展性。Oracle 本身是一個封閉的系統，用 Oracle 怎么做擴展？用現在一個時髦的說法就是做“分庫分表”。

        我們知道一臺 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 的發展需要專門一個章節來講，想先睹為快的可以看一下筆者對章文嵩的專訪。        

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

        有些技術的發展是順其自然的，有些卻是突如其來的。到 2007 年的時候，我們已經有幾百臺應用服務器了，這上面的 Java 應用服務器是 WebLogic，而 WebLogic 是非常貴的，比這些服務器本身都貴。有一段時間多隆研究了一下 JBoss，說我們換掉 WebLogic 吧，于是又省下了不少銀兩。那一年，老馬舉辦了第一屆的“網俠大會”，會上來的大俠中有一位是上文提到的章文嵩，還有一位曾經在 JBoss 團隊工作，我們也把這位大俠留下了，這樣我們用起 JBoss 更加有底氣了。        

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

        架構圖如下：

        下集預告：創造技術分布式文件系統 TFS、分布式 kv 緩存 tair、搜索引擎升級