捨得網支撐1000萬pv數據庫緩存系統

說是支持1億pv/天，也許有點誇張，也是爲了吸引您能點進來，若是您能認真看完相信也不會讓您失望，固然，確定有不少「高手」會對此會嗤之以鼻，不要緊，有不少眼高手低的人總喜歡評論別人卻從不會看清本身。 

若是你們真想支持我、支持中國人開源項目，請把該文貼到本身的博客中或者收藏本文，記得包含文檔的下載地址！！！！！！！謝謝。 

我說的系統主要是構建在hibernate之上的高效數據庫緩存系統，其中包含了分佈式解決方案，該系統已經應用在捨得網上了，沒有發現大問題，本人也相信該系統已經足夠強大，應付數百萬IP/天的應用都不是問題，我這麼說確定有人會對此表示懷疑，其實系統到底能撐多少IP/天不在於系統自己而是在於使用該系統的人。 
代碼看上去很簡單，其實倒是兩年經驗的總結，整過過程也遇到了不少難點，最後一一解決了，因此也請各位珍惜他人的勞動成果。本系統很是簡潔易用，主程序 BaseManager.java不到1000行代碼，用「精悍」來形容絕對不爲過，1000行代碼卻包含了數據庫對象的緩存、列表和長度的緩存、按字段散列緩存、update延時更新、自動清除列表緩存等功能，用它來實現像論壇、博客、校友錄、交友社區等絕大部分應用網站都足夠了。 

我在理想狀態下作了壓力測試，在沒有數據庫操做的jsp頁面(捨得網新首頁)裏能夠完成2000多requests每秒（正常狀況可能有1/1000的 request有數據庫查詢，其他999/1000都是直接從緩存裏讀取），物品詳情頁每秒可完成3000多requests，純靜態html頁面也只能完成7000多requests/秒，我對首頁進行了三個小時的壓力測試，完成了24850800個requests，java一點事都沒有，內存沒有上漲。按照2000個requests/秒算，一天按15小時計算，那麼天天能完成3600*15*2000=1億零8百萬requests，固然這是理想狀態，實際狀態就算打一折，還能完成1000萬pv/天，要知道，這只是一個普通1萬3千塊錢買的服務器，內存4G，CPU2個，LinuxAS4系統，apache2.0.63/resin2.1.17/jdk6.0的環境。 

如今進入正題。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 

爲何要用緩存？若是問這個問題說明你仍是新手，數據庫吞吐量畢竟有限，每秒讀寫5000次了不得了，若是不用緩存，假設一個頁面有100個數據庫操做，50個用戶併發數據庫就歇菜，這樣最多能支撐的pv也就50*3600*15=270萬，並且數據庫服務器累得半死，搞很差何時就累死了。個人這套緩存系統比單獨用memcached作緩存還要強大，至關於在memcached上再作了兩級緩存，你們都知道memcached很強了，可是吞吐量仍是有限，每秒20000次get和put當遇到超大規模的應用時仍是會歇菜，本地HashMap每秒可執行上百萬次put和get，在這上面損耗的性能幾乎能夠忽略不記了。舒適提示：能不用分佈式的時候就不要用分佈式，非用分佈式的時候再考慮用memcached，個人緩存系統在這方面都已經實現了，改個配置就能夠了，有興趣的能夠仔細測試測試！ 

通常數據庫緩存在我看來包含四種。第一種：單個對象的緩存（一個對象就是數據庫一行記錄），對於單個對象的緩存，用HashMap就能夠了，稍微複雜一點用LRU算法包裝一個HashMap，再複雜一點的分佈式用memcached便可，沒什麼太難的；第二種：列表緩存，就像論壇裏帖子的列表；第三種：長度的緩存，好比一個論壇板塊裏有多少個帖子，這樣才方便實現分頁。第四種：複雜一點的group，sum，count查詢，好比一個論壇裏按點擊數排名的最HOT的帖子列表。第一種比較好實現，後面三種比較困難，彷佛沒有通用的解決辦法，我暫時以列表緩存（第二種）爲例分析。 

mysql和hibernate的底層在作通用的列表緩存時都是根據查詢條件把列表結果緩存起來，可是隻要該表的記錄有任何變化（增長/刪除/修改），列表緩存要所有清除，這樣只要一個表的記錄常常變化（一般狀況都會這樣），列表緩存幾乎失效，命中率過低了。 

本人想了一個辦法改善了列表緩存，當表的記錄有改變時，遍歷全部列表緩存，只有那些被影響到的列表緩存纔會被刪除，而不是直接清除全部列表緩存，好比在一個論壇版（id=1）裏增長了一個帖子，那麼只要清除id=1這個版對應的列表緩存就能夠了，版id=2就不用清除了。這樣處理有個好處，能夠緩存各類查詢條件（如等於、大於、不等於、小於）的列表緩存，但也有個潛在的性能問題，因爲須要遍歷，CPU符合比較大，若是列表緩存最大長度設置成10000，兩個4核的CPU每秒也只能遍歷完300屢次，這樣若是每秒有超過300個insert/update/delete，系統就吃不消了。 

在前面兩種解決辦法都不完美的狀況下，本人和同事通過幾個星期的思索，總算得出了根據表的某幾個字段作散列的緩存辦法，這種辦法無需大規模遍歷，因此 CPU符合很是小，因爲這種列表緩存按照字段作了散列，因此命中率極高。思路以下：每一個表有3個緩存Map（key=value鍵值對），第一個Map是對象緩存A，在A中，key是數據庫的id，Value是數據庫對象（也就是一行數據）；第二個Map是通用列表緩存B，B的最大長度通常1000左右，在B中，key是查詢條件拼出來的String（如start=0,length=15#active=0#state=0），Value是該條件查詢下的全部id組成的List；第三個Map是散列緩存C，在C中，key是散列的字段（如根據userId散列的話，其中某個key就是 userId=109這樣的String）組成的String，value是一個和B相似的HashMap。其中只有B這個Map是須要遍歷的，不知道說明白了沒有，看完小面這個例子應該就明白了，就用論壇的回覆表做說明，假設回覆表T中假設有字段id，topicId，postUserId等字段（topicId就是帖子的id，postUserId是發佈者id）。 

第一種狀況，也是最經常使用的狀況，就是獲取一個帖子對應的回覆，sql語句應該是象 
select id from T where topicId=2008 order by createTime desc limit 0,5 
select id from T where topicId=2008 order by createTime desc limit 5,5 
select id from T where topicId=2008 order by createTime desc limit 10,5 
的樣子，那麼這種列表很顯然用topicId作散列是最好的，把上面三個列表緩存（能夠是N個）都散列到key是topicId=2008這一個Map 中，當id是2008的帖子有新的回覆時，系統自動把key是topicId=2008的散列Map清除便可。因爲這種散列不須要遍歷，所以能夠設置成很大，例如100000，這樣10萬個帖子對應的全部回覆列表均可以緩存起來，當有一個帖子有新的回覆時，其他99999個帖子對應的回覆列表都不會動，緩存的命中率極高。 

第二種狀況，就是後臺須要顯示最新的回覆，sql語句應該是象 
select id from T order by createTime desc limit 0,50 
的樣子，這種狀況不須要散列，由於後臺不可能有太多人訪問，經常使用列表也不會太多，因此直接放到通用列表緩存B中便可。 

第三種狀況，獲取一個用戶的回覆，sql語句象 
select id from T where userId=2046 order by createTime desc limit 0,15 
select id from T where userId=2046 order by createTime desc limit 15,15 
select id from T where userId=2046 order by createTime desc limit 30,15 
的樣子，那麼這種列表和第一種狀況相似，用userId作散列便可。 

第四種狀況，獲取一個用戶對某個帖子的回覆，sql語句象 
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 0,15 
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 15,15 
的樣子，這種狀況比較少見，通常以topicId=2008爲準，也放到key是topicId=2008這個散列Map裏便可。 

總結：這種緩存思路能夠存儲大規模的列表，緩存命中率極高，所以能夠承受超大規模的應用，可是須要技術人員根據自身業務邏輯來配置須要作散列的字段，通常用一個表的索引鍵作散列（注意順序，最散的字段放前面），假設以userId爲例，能夠存儲N個用戶的M種列表，若是某個用戶的相關數據發生變化，其他 N-1個用戶的列表緩存紋絲不動。以上說明的都是如何緩存列表，緩存長度和緩存列表思路徹底同樣，如緩存象select count(*) from T where topicId=2008這樣的長度，也是放到topicId=2008這個散列Map中。若是再配合好使用mysql的內存表和memcached，加上F5設備作分佈式負載均衡，該系統對付像1000萬IP/天這種規模級的應用都足夠了，除搜索引擎外通常的應用網站到不了這種規模。 

再次申明：系統究竟是不是強大不在系統自己而在於使用該系統的人！！！ 

這個緩存系統是我和同事幾年經驗的總結，看似簡單，其實也沒那麼簡單，把它做爲開源有下面幾個目的：第一，真的但願有不少人能用它；第二：但願更多的人可以完善和改進它；第三：但願你們能聚到一塊兒爲通用高效數據庫緩存構架做出貢獻，畢竟，數據庫操做是各類應用最經常使用的操做，也是最容易產生性能瓶頸的地方。 

Zip包中包含了配置方法和測試用的jsp，只要把它配置成一個web應用就能夠快速調試並看到緩存的力量了，文檔和下載地址是http://shedewang.com/akaladocs/api/com/akala/dbcache/core/BaseManager.html。羣組的地址是http://groups.csdn.net/shedewang_db_cache  配置說明文件在docs/開始配置.txt裏有說明。  最後囉嗦一句，若是你們真想支持我、支持中國人開源項目，請把該文貼到本身的博客中或者收藏本文，記得包含文檔的下載地址！！！！！！！謝謝。thank you and Good luck。