優酷網的架構學習筆記

一、**基本資料概覽

硬體方面，優酷網引進的戴爾伺服器主要以 poweredge 1950與poweredge 860為主，儲存陣列以戴爾md1000為主，2007的資料表明，優酷網已有1000多台伺服器遍布在全國各大省市，現在應該更多了吧。

二、**前端框架

從一開始，優酷網就自建了一套cms來解決前端的頁面顯示，各個模組之間分離得比較恰當，前端可擴充套件性很好，ui的分離，讓開發與維護變得十分簡單和靈活，下圖是優酷前端的模組呼叫關係：

這樣，就根據module、method及params來確定呼叫相對獨立的模組，顯得非常簡潔。下面附一張優酷的前端區域性架構圖：

三、資料庫架構

應該說優酷的資料庫架構也是經歷了許多波折，從一開始的單台mysql伺服器（just running）到簡單的mysql主從複製、ssd優化、垂直分庫、水平sharding分庫，這一系列過程只有經歷過才會有更深的體會吧，就像myspace的架構經歷一樣，架構也是一步步慢慢成長和成熟的。

1、簡單的mysql主從複製:

mysql的主從複製解決了資料庫的讀寫分離，並很好的提公升了讀的效能，其原來圖如下：

其主從複製的過程如下圖所示：

但是，主從複製也帶來其他一系列效能瓶頸問題：

寫入無法擴充套件

寫入無法快取

複製延時

鎖表率上公升

表變大，快取率下降

2、mysql垂直分割槽

如果把業務切割得足夠獨立，那把不同業務的資料放到不同的資料庫伺服器將是乙個不錯的方案，而且萬一其中乙個業務崩潰了也不會影響其他業務的正常進行，並且也起到了負載分流的作用，大大提公升了資料庫的吞吐能力。經過垂直分割槽後的資料庫架構圖如下：

然而，儘管業務之間已經足夠獨立了，但是有些業務之間或多或少總會有點聯絡，如使用者，基本上都會和每個業務相關聯，況且這種分割槽方式，也不能解決單張表資料量暴漲的問題，因此為何不試試水平sharding呢？

3、mysql水平分片（sharding）

這是乙個非常好的思路，將使用者按一定規則（按id雜湊）分組，並把該組使用者的資料儲存到乙個資料庫分片中，即乙個sharding，這樣隨著使用者數量的增加，只要簡單地配置一台伺服器即可，原理圖如下：

但是，優酷是如何解決跨shard的查詢呢，這個是個難點，據介紹優酷是盡量不跨shard查詢，實在不行通過多維分片索引、分布式搜尋引擎，下策是分布式資料庫查詢（這個非常麻煩而且耗效能）

四、快取策略

貌似大的系統都對「快取」情有獨鍾，從http快取到memcached記憶體資料快取，但優酷表示沒有用記憶體快取，理由如下：

避免記憶體拷貝，避免記憶體鎖

而且squid 的 write() 使用者程序空間有消耗，lighttpd 1.5 的 aio(非同步i/o) 讀取檔案到使用者記憶體導致效率也比較低下。