網站高資料量訪問解決方案
資料庫一向是網站架構中最具挑戰性的，瓶頸通常出現在這裡。又拍網的照片資料量很大，資料庫也幾度出現嚴重的壓力問題。 因此，這裡我主要介紹一下又拍網在分庫設計這方面的一些嘗試。
又拍網是一個照片分享社群，從2005年6月至今積累了260萬用戶，1.1億張照片，目前的日訪問量為200多萬。5年的發展歷程裡經歷過許多起 伏，也積累了一些經驗，在這篇文章裡，我要介紹一些我們在技術上的積累。
又拍網和大多數Web2.0站點一樣，構建於大量開源軟體之上，包括MySQL
、PHP
、nginx
、Python
、memcached
、redis
、Solr
、Hadoop
和RabbitMQ
等
等。又拍網的伺服器端開發語言主要是
圖1： 開發語言
由於PHP
的
單執行緒模型，我們把耗時較久的運算和I/O操作從HTTP請求週期中分離出來， 交給由Python
實現的
任務程序來完成，以保證請求響應速度。這些任務主要包括：郵件傳送、資料索引、資料聚合和好友動態推送（稍候會有介紹）等等。通常這些任務由使用者觸發，並
且，使用者的一個行為可能會觸發多種任務的執行。 比如，使用者上傳了一張新的照片，我們需要更新索引，也需要向他的朋友推送一條新的動態。
圖2： PHP和Python的協作
資料庫一向是網站架構中最具挑戰性的，瓶頸通常出現在這裡。又拍網的照片資料量很大，資料庫也幾度出現嚴重的壓力問題。 因此，這裡我主要介紹一下又拍網在分庫設計這方面的一些嘗試。
分庫設計
和很多使用MySQL 的 2.0站點一樣，又拍網的MySQL 集 群經歷了從最初的一個主庫一個從庫、到一個主庫多個從庫、 然後到多個主庫多個從庫的一個發展過程。
最初是由一臺主庫和一臺從庫組成，當時從庫只用作備份和容災，當主庫出現故障時，從庫就手動變成主庫，一般情況下，從庫不作讀寫操作（同步除外）。
隨著壓力的增加，我們加上了
在參考了一些相關產品和其它網站的做法後，我們決定進行資料庫拆分。也就是將資料存放到不同的資料庫伺服器中，一般可以按兩個緯度來拆分資料:
垂直拆分 ：是指按功能模組拆分，比如可以將群組相關表和照片相關表存放在不同的資料庫中，這種方式多個數據庫之 間的表結構不同 。
水平拆分 ：而水平拆分是將同一個表的資料進行分塊儲存到不同的資料庫中，這些資料庫中的表結構 完全相同 。
拆分方式
一般都會先進行垂直拆分，因為這種方式拆分方式實現起來比較簡單，根據表名訪問不同的資料庫就可以了。但是垂直拆分方式並不能徹底解決所有壓力問 題，另外，也要看應用型別是否合適這種拆分方式。如果合適的話，也能很好的起到分散資料庫壓力的作用。比如對於豆瓣 我覺得比較適合 採用垂直拆分， 因為豆瓣 的 各核心業務/模組（書籍、電影、音樂）相對獨立，資料的增加速度也比較平穩。不同的是，又拍網的核心業務物件是使用者上傳的照片，而照片資料的增加速度隨著 使用者量的增加越來越快。壓力基本上都在照片表上，顯然垂直拆分並不能從根本上解決我們的問題，所以，我們採用水平拆分的方式。
拆分規則
水平拆分實現起來相對複雜，我們要先確定一個拆分規則，也就是按什麼條件將資料進行切分。 一般2.0網站都以使用者為中心，資料基本都跟隨使用者，比如使用者的照片、朋友和評論等等。因此一個比較自然的選擇是根據使用者來切分。每個使用者都對應一個數據 庫，訪問某個使用者的資料時， 我們要先確定他/她所對應的資料庫，然後連線到該資料庫進行實際的資料讀寫。
那麼，怎麼樣對應使用者和資料庫呢？我們有這些選擇：
按演算法對應
最簡單的演算法是按使用者ID的奇偶性來對應，將奇數ID的使用者對應到資料庫A，而偶數ID的使用者則對應到資料庫B。這個方法的最大問題是，只能分成兩 個庫。另一個演算法是按使用者ID所在區間對應，比如ID在0-10000之間的使用者對應到資料庫A， ID在10000-20000這個範圍的對應到資料庫B，以此類推。按演算法分實現起來比較方便，也比較高效，但是不能滿足後續的伸縮性要求，如果需要增加 資料庫節點，必需調整演算法或移動很大的資料集， 比較難做到在不停止服務的前提下進行擴充資料庫節點。
按索引 / 對映表對應
這種方法是指建立一個索引表，儲存每個使用者的ID和資料庫ID的對應關係，每次讀寫使用者資料時先從這個表獲取對應資料庫。新使用者註冊後，在所有可用 的資料庫中隨機挑選一個為其建立索引。這種方法比較靈活，有很好的伸縮性。一個缺點是增加了一次資料庫訪問，所以效能上沒有按演算法對應好。
比較之後，我們採用的是索引表的方式，我們願意為其靈活性損失一些效能，更何況我們還有memcached ， 因為索引資料基本不會改變的緣故，快取命中率非常高。所以能很大程度上減少了效能損失。
圖4： 資料訪問過程
索引表的方式能夠比較方便地新增資料庫節點，在增加節點時，只要將其新增到可用資料庫列表裡即可。 當然如果需要平衡各個節點的壓力的話，還是需要進行資料的遷移，但是這個時候的遷移是少量的，可以逐步進行。要遷移使用者A的資料，首先要將其狀態置為遷 移資料中 ，這個狀態的使用者不能進行寫操作，並在頁面上進行提示。 然後將使用者A的資料全部複製到新增加的節點上後，更新對映表，然後將使用者A的狀態置為正常 ，最後將原來對應的資料庫上 的資料刪除。這個過程通常會在臨晨進行，所以，所以很少會有使用者碰到遷移資料中 的情況。
當然，有些資料是不屬於某個使用者的，比如系統訊息、配置等等，我們把這些資料儲存在一個全域性庫中。
問題
分庫會給你在應用的開發和部署上都帶來很多麻煩。
不能執行跨庫的關聯查詢
如果我們需要查詢的資料分佈於不同的資料庫，我們沒辦法通過JOIN的方式查詢獲得。比如要獲得好友的最新照片，你不能保證所有好友的資料都在同一 個數據庫裡。一個解決辦法是通過多次查詢，再進行聚合的方式。我們需要儘量避免類似的需求。有些需求可以通過儲存多份資料來解決，比如User-A和 User-B的資料庫分別是DB-1和DB-2， 當User-A評論了User-B的照片時，我們會同時在DB-1和DB-2中儲存這條評論資訊，我們首先在DB-2中的photo_comments表 中插入一條新的記錄，然後在DB-1中的user_comments表中插入一條新的記錄。這兩個表的結構如下圖所示。這樣我們可以通過查詢 photo_comments表得到User-B的某張照片的所有評論， 也可以通過查詢user_comments表獲得User-A的所有評論。另外可以考慮使用全文檢索工具來解決某些需求， 我們使用Solr 來 提供全站標籤檢索和照片搜尋服務。
圖5： 評論表結構
不能保證資料的一致 / 完整性
跨庫的資料沒有外來鍵約束，也沒有事務保證。比如上面的評論照片的例子， 很可能出現成功插入photo_comments表，但是插入user_comments表時卻出錯了。一個辦法是在兩個庫上都開啟事務，然後先插入 photo_comments，再插入user_comments， 然後提交兩個事務。這個辦法也不能完全保證這個操作的原子性。
所有查詢必須提供資料庫線索
比如要檢視一張照片，僅憑一個照片ID是不夠的，還必須提供上傳這張照片的使用者的ID（也就是資料庫線索），才能找到它實際的存放位置。因此，我們 必須重新設計很多URL地址，而有些老的地址我們又必須保證其仍然有效。我們把照片地址改成/photos/{username}/{photo_id} /的形式，然後對於系統升級前上傳的照片ID， 我們又增加一張對映表，儲存photo_id和user_id的對應關係。當訪問老的照片地址時，我們通過查詢這張表獲得使用者資訊, 然後再重定向到新的地址。
自增 ID
如果要在節點資料庫上使用自增欄位，那麼我們就不能保證全域性唯一。這倒不是很嚴重的問題，但是當節點之間的資料發生關係時，就會使得問題變得比較麻 煩。我們可以再來看看上面提到的評論的例子。如果photo_comments表中的comment_id的自增欄位，當我們在DB- 2.photo_comments表插入新的評論時， 得到一個新的comment_id，假如值為101，而User-A的ID為1，那麼我們還需要在DB-1.user_comments表中插入(1, 101 ...)。 User-A是個很活躍的使用者，他又評論了User-C的照片，而User-C的資料庫是DB-3。 很巧的是這條新評論的ID也是101，這種情況很用可能發生。那麼我們又在DB-1.user_comments表中插入一行像這樣(1, 101 ...)的資料。 那麼我們要怎麼設定user_comments表的主鍵呢（標識一行資料）？可以不設啊，不幸的是有的時候（框架、快取等原因）必需設定。那麼可以以 user_id、 comment_id和photo_id為組合主鍵，但是photo_id也有可能一樣（的確很巧）。看來只能再加上photo_owner_id了， 但是這個結果又讓我們實在有點無法接受，太複雜的組合鍵在寫入時會帶來一定的效能影響，這樣的自然鍵看起來也很不自然。所以，我們放棄了在節點上使用自增 欄位，想辦法讓這些ID變成全域性唯一。為此增加了一個專門用來生成ID的資料庫，這個庫中的表結構都很簡單，只有一個自增欄位id。 當我們要插入新的評論時，我們先在ID庫的photo_comments表裡插入一條空的記錄，以獲得一個唯一的評論ID。 當然這些邏輯都已經封裝在我們的框架裡了，對於開發人員是透明的。 為什麼不用其它方案呢，比如一些支援incr操作的Key-Value資料庫。我們還是比較放心把資料放在MySQL裡。 另外，我們會定期清理ID庫的資料，以保證獲取新ID的效率。
實現
我們稱前面提到的一個數據庫節點為Shard，一個Shard由兩個臺物理伺服器組成， 我們稱它們為Node-A和Node-B，Node-A和Node-B之間是配置成Master-Master相互複製的。 雖然是Master-Master的部署方式，但是同一時間我們還是隻使用其中一個，原因是複製的延遲問題， 當然在Web應用裡，我們可以在使用者會話裡放置一個A或B來保證同一使用者一次會話裡只訪問一個數據庫， 這樣可以避免一些延遲問題。但是我們的Python 任務是 沒有任何狀態的，不能保證和PHP 應 用讀寫相同的資料庫。那麼為什麼不配置成Master-Slave呢？我們覺得只用一臺太浪費了，所以我們在每臺伺服器上都建立多個邏輯資料庫。 如下圖所示，在Node-A和Node-B上我們都建立了shard_001和shard_002兩個邏輯資料庫， Node-A上的shard_001和Node-B上的shard_001組成一個Shard，而同一時間只有一個邏輯資料庫處於Active狀態。 這個時候如果需要訪問Shard-001的資料時，我們連線的是Node-A上的shard_001， 而訪問Shard-002的資料則是連線Node-B上的shard_002。以這種交叉的方式將壓力分散到每臺物理伺服器上。 以Master-Master方式部署的另一個好處是，我們可以不停止服務的情況下進行表結構升級， 升級前先停止複製，升級Inactive的庫，然後升級應用，再將已經升級好的資料庫切換成Active狀態， 原來的Active資料庫切換成Inactive狀態，然後升級它的表結構，最後恢復複製。 當然這個步驟不一定適合所有升級過程，如果表結構的更改會導致資料複製失敗，那麼還是需要停止服務再升級的。
圖6： 資料庫佈局
前面提到過新增伺服器時，為了保證負載的平衡，我們需要遷移一部分資料到新的伺服器上。為了避免短期內遷移的必要，我們在實際部署的時候，每臺機器 上部署了8個邏輯資料庫， 新增伺服器後，我們只要將這些邏輯資料庫遷移到新伺服器就可以了。最好是每次新增一倍的伺服器， 然後將每臺的1/2邏輯資料遷移到一臺新伺服器上，這樣能很好的平衡負載。當然，最後到了每臺上只有一個邏輯庫時，遷移就無法避免了，不過那應該是比較久 遠的事情了。
我們把分庫邏輯都封裝在我們的PHP框架裡了，開發人員基本上不需要被這些繁瑣的事情困擾。下面是使用我們的框架進行照片資料的讀寫的一些例子:
| $Photos
= new ShardedDBTable('Photos', 'yp_photos', 'user_id', array( 'photo_id' => array('type' => 'long', 'primary' => true, 'global_auto_increment' => true), 'user_id' => array('type' => 'long'), 'title' => array('type' => 'string'), 'posted_date' => array('type' => 'date'), )); $photo = $Photos->new_object(array('user_id' => 1, 'title' => 'Workforme')); $photo->insert(); // 載入ID為10001的照片，注意第一個引數為使用者ID $photo = $Photos->load(1, 10001); // 更改照片屬性 $photo->title = 'Database Sharding'; $photo->update(); // 刪除照片 $photo->delete(); // 獲取ID為1的使用者在2010-06-01之後上傳的照片 $photos = $Photos->fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01')); ?> |
首先要定義一個ShardedDBTable物件，所有的API都是通過這個物件開放。第一個引數是物件型別名稱， 如果這個名稱已經存在，那麼將返回之前定義的物件。你也可以通過get_table('Photos')這個函式來獲取之前定義的Table物件。 第二個引數是對應的資料庫表名，而第三個引數是資料庫線索欄位，你會發現在後面的所有API中全部需要指定這個欄位的值。 第四個引數是欄位定義，其中photo_id欄位的global_auto_increment屬性被置為true，這就是前面所說的全域性自增ID， 只要指定了這個屬性，框架會處理好ID的事情。
如果我們要訪問全域性庫中的資料，我們需要定義一個DBTable物件。
| <?php $Users = new DBTable('Users', 'yp_users', array( 'user_id' => array('type' => 'long', 'primary' => true, 'auto_increment' => true), 'username' => array('type' => 'string'), )); ?> |
DBTable是ShardedDBTable的父類，除了定義時引數有些不同（DBTable不需要指定資料庫線索欄位），它們提供一樣的 API。
快取
我們的框架提供了快取功能，對開發人員是透明的。
| <?php $photo = $Photos->load(1, 10001); ?> |
比如上面的方法呼叫，框架先嚐試以Photos-1-10001為Key在快取中查詢，未找到的話再執行資料庫查詢並放入快取。當更改照片屬性或刪 除照片時，框架負責從快取中刪除該照片。這種單個物件的快取實現起來比較簡單。稍微麻煩的是像下面這樣的列表查詢結果的快取。
| <?php $photos = $Photos->fetch(array('user_id' => 1, 'posted_date__gt' => '2010-06-01')); ?> |
我們把這個查詢分成兩步，第一步先查出符合條件的照片ID，然後再根據照片ID分別查詢具體的照片資訊。 這麼做可以更好的利用快取。第一個查詢的快取Key為Photos-list-{shard_key}-{md5(查詢條件SQL語句)}， Value是照片ID列表（逗號間隔）。其中shard_key為user_id的值1。目前來看，列表快取也不麻煩。 但是如果使用者修改了某張照片的上傳時間呢，這個時候快取中的資料就不一定符合條件了。所以，我們需要一個機制來保證我們不會從快取中得到過期的列表資料。 我們為每張表設定了一個revision，當該表的資料發生變化時（呼叫insert/update/delete方法）， 我們就更新它的revision，所以我們把列表的快取Key改為Photos-list-{shard_key}-{md5(查詢條件SQL語 句)}-{revision}， 這樣我們就不會再得到過期列表了。
revision資訊也是存放在快取裡的，Key為Photos-revision。這樣做看起來不錯，但是好像列表快取的利用率不會太高。因為我 們是以整個資料型別的revision為快取Key的字尾，顯然這個revision更新的非常頻繁，任何一個使用者修改或上傳了照片都會導致它的更新，哪 怕那個使用者根本不在我們要查詢的Shard裡。要隔離使用者的動作對其他使用者的影響，我們可以通過縮小revision的作用範圍來達到這個目的。 所以revision的快取Key變成Photos-{shard_key}-revision，這樣的話當ID為1的使用者修改了他的照片資訊時， 只會更新Photos-1-revision這個Key所對應的revision。
因為全域性庫沒有shard_key，所以修改了全域性庫中的表的一行資料，還是會導致整個表的快取失效。 但是大部分情況下，資料都是有區域範圍的，比如我們的幫助論壇的主題帖子， 帖子屬於主題。修改了其中一個主題的一個帖子，沒必要使所有主題的帖子快取都失效。 所以我們在DBTable上增加了一個叫isolate_key的屬性。
| <?php $GLOBALS['Posts'] = new DBTable('Posts', 'yp_posts', array( 'topic_id' => array('type' => 'long', 'primary' => true), 'post_id' => array('type' => 'long', 'primary' => true, 'auto_increment' => true), 'author_id' => array('type' => 'long'), 'content' => array('type' => 'string'), 'posted_at' => array('type' => 'datetime'), 'modified_at' => array('type' => 'datetime'), 'modified_by' => array('type' => 'long'), ), 'topic_id'); ?> |
注意建構函式的最後一個引數topic_id就是指以欄位topic_id作為isolate_key，它的作用和shard_key一樣用於隔離 revision的作用範圍。
ShardedDBTable繼承自DBTable，所以也可以指定isolate_key。 ShardedDBTable指定了isolate_key的話，能夠更大幅度縮小revision的作用範圍。 比如相簿和照片的關聯表yp_album_photos，當用戶往他的其中一個相簿裡添加了新的照片時， 會導致其它相簿的照片列表快取也失效。如果我指定這張表的isolate_key為album_id的話， 我們就把這種影響限制在了本相簿內。
我們的快取分為兩級，第一級只是一個PHP陣列，有效範圍是Request。而第二級是memcached。這麼做的原因是，很多資料在一個 Request週期內需要載入多次，這樣可以減少memcached的網路請求。另外我們的框架也會盡可能的傳送memcached的gets命令來獲取 資料， 從而減少網路請求。
總結
這個架構使得我們在很長一段時間內都不必再為資料庫壓力所困擾。我們的設計很多地方參考了netlog 和flickr 的實現，因此非常感謝他們將一些實現細節釋出出來。
接下來就可以根據這些分析來設計應 用系統的查詢框架。在J2EE架構下，對於大資料量的查詢主要採取以下兩種方法：
基於快取的方式：
從資料庫得到全部（部分）資料，並 將其在伺服器端進行快取，接下來的客戶端請求，將直接從快取中取得需要的資料。這其實就是經典的Value List Handler模式的原理（如下 圖），該模式建立一個ValueListHandler物件來控制查詢的執行以及結果集的快取，它通過DAO(Data Access Object)來 執行查詢，並將資料庫返回的結果集（傳輸物件Transfer Object的集合）快取起來，接下來的客戶端查詢請求將直接從快取中獲得。它的特點主要 體現在兩點：伺服器端快取資料，每次只返回客戶端本次操作所需的資料，通過這兩個措施來減少資料庫的訪問次數以及增加客戶端的響應速度，達到最優的查詢效 果。它主要適用於資料量不是非常大，變化不是很頻繁（或者變化頻繁但是有規律）且不具有成長性的情況，比如人事系統的大部分查詢就非常適合採取這種方式。
採用這種方式，要特別注意第一次查 詢問題，避免響應效能達不到要求，因為每個查詢第一次都需要連線資料庫，從中獲取資料並快取起來，所以第一次查詢會比接下來的查詢都顯得更慢一些。
對於資料的快取，有以下幾種實現方 式：
直接快取在伺服器 端
Value List Handler 模式就採取這種方式，並且可以根據不同的情況採取不同的快取策略，比如Transfer Object集合，CachedRowSet等，這取決於你的 DAO實現策略。
用臨時表來儲存查 詢結果
WLDJ（www.sys- con.com/weblogic/）雜誌2004年第7期上有一篇名為“Handling Large Database Result Sets”的 文章，它詳細介紹瞭如何利用臨時表來改良Value List Handler模式以支援大型的J2EE應用。
基於查詢的方式：
不進行資料快取，客戶端的每次資料 請求都需要進行實際的資料庫查詢，這種方式適用於量大，具有成長性，變化頻繁的資料。該方式的特點是每次查詢的時間都大致相等，不會存在基於快取的方式的 第一次查詢問題，但後續的操作會比快取方式的查詢慢一些。採取這種方式的查詢框架設計更具有可擴充套件性以及對資料變化更好的應變能力，在大部分的業務系統中 都推薦使用該方式。
使用這種方法，每次查詢應該只從數 據庫獲得客戶端所需的資料，這樣就涉及到如何獲得部分資料的問題。一種是查詢出符合條件的所有記錄，然後遍歷該記錄集，根據上次查詢結果來比較記錄中的某 些欄位獲取本次查詢需要的部分資料，由於要對記錄集進行遍歷，效率不高，一般都不推薦使用，而往往採用另一種增加sql查詢語句條件的方式。
Java的資料庫連線通常利用 JDBC（Java Database Connectivity）來做的，JDBC是一個Java擴充套件API，它為程式設計者提供了基於SQL查詢的資料訪問能力。但是，通過JDBC連線訪問資料 庫伺服器的能力，對於有大資料量訪問的應用程式還是不夠的。引入連線池的目的就是改善依賴於資料庫的java伺服器程式碼的效能和併發性，解決三層架構中的 中間層與第三層之間的開銷。
資料庫連線是一種關鍵的有限的昂貴 的資源，這一點在多使用者的網頁應用程式中體現得尤為突出。對資料庫連線的管理能顯著影響到整個應用程式的伸縮性和健壯性，影響到程式的效能指標。資料庫連 接池正是針對這個問題提出來的。
連線池是資料庫連線的緩衝區，它位 於記憶體中，由於使用了連線池，所以連線可以被重複使用，而無需在每次使用完後，都需要進行建立和撤銷操作。所以採用連線池具有減少工作量，更加容易移植和 總體效能更高的優點。
資料庫連線池負責分配、管理和釋放 資料庫連線，它允許應用程式重複使用一個現有的資料庫連線，而再不是重新建立一個；釋放空閒時間超過最大空閒時間的資料庫連線來避免因為沒有釋放資料庫連 接而引起的資料庫連線遺漏。這項技術能明顯提高對資料庫操作的效能。
資料庫連線池在初始化時將建立一定 數量的資料庫連線放到連線池中，這些資料庫連線的數量是由最小資料庫連線數來設定的。無論這些資料庫連線是否被使用，連線池都將一直保證至少擁有這麼多的 連線數量。連線池的最大資料庫連線數量限定了這個連線池能佔有的最大連線數，當應用程式向連線池請求的連線數超過最大連線數量時，這些請求將被加入到等待 佇列中。資料庫連線池的最小連線數和最大連線數的設定要考慮到下列幾個因素：
1) 最小連線數是連線池一直保持的資料庫連線，所以如果應用程式對資料庫連線的使用量不大，將會有大量的資料庫連線資源被浪費；
2) 最大連線數是連線池能申請的最大連線數，如果資料庫連線請求超過此數，後面的資料庫連線請求將被加入到等待佇列中，這會影響之後的資料庫操作。
3) 如果最小連線數與最大連線數相差太大，那麼最先的連線請求將會獲利，之後超過最小連線數量的連線請求等價於建立一個新的資料庫連線。不過，這些大於最小連 接數的資料庫連線在使用完不會馬上被釋放，它將被放到連線池中等待重複使用或是空閒超時後被釋放。
基於Web的中介軟體產品較多,它們 都可以實現池的作用，在我們中南電力設計院的質量管理資訊系統，電子媒體查詢系統和OA系統中選用Tomcat作為資料庫中介軟體進行資料庫連線池管理，利 用Tomcat自身的管理機制來監視資料庫連線的數量、使用情況, 程式效率得到顯著提高。（限於篇幅，連線池配置程式碼略）
目前隨著企業網路應用的發展，大數 據量訪問的效率問題已經越來越突出，甚至在某些地方成了企業發展的瓶頸。在中南電力設計院的MIS軟體開發過程中也遇到同樣的問題，曾經出現在網頁上生成 一個樹狀結構需要等待30秒左右的情況，而那時後臺數據還不到一萬條，經過對軟體的資料訪問效率的研究之後，提出了這套解決方案，同樣的一個樹狀結構使用者 最多隻需要等待3秒鐘就可以完成。經過幾年的執行與除錯，目前各系統總體體能表現非常地穩定，能夠滿足企業使用者需要。