原文：http://topic.csdn.net/u/20080722/22/3a63114f-31ea-4174-ba9f-0c0d0c8cb293.html
為什么要用緩存？如果問這個(gè)問題說(shuō)明你還是新手，數(shù)據(jù)庫(kù)吞吐量畢竟有限，每秒讀寫5000次了不起了，如果不用緩存，假設(shè)一個(gè)頁(yè)面有100個(gè)數(shù)據(jù)庫(kù)操作，50個(gè)用戶并發(fā)數(shù)據(jù)庫(kù)就歇菜，這樣最多能支撐的pv也就50*3600*15=270萬(wàn)，而且數(shù)據(jù)庫(kù)服務(wù)器累得半死，搞不好什么時(shí)候就累死了。我的這套緩存系統(tǒng)比單獨(dú)用memcached做緩存還要強(qiáng)大，相當(dāng)于在memcached上再做了兩級(jí)緩存，大家都知道m(xù)emcached很強(qiáng)了，但是吞吐量還是有限，每秒20000次get和put當(dāng)遇到超大規(guī)模的應(yīng)用時(shí)還是會(huì)歇菜，本地HashMap每秒可執(zhí)行上百萬(wàn)次put和get，在這上面損耗的性能幾乎可以忽略不記了。溫馨提示：能不用分布式的時(shí)候就不要用分布式，非用分布式的時(shí)候再考慮用memcached，我的緩存系統(tǒng)在這方面都已經(jīng)實(shí)現(xiàn)了，改個(gè)配置就可以了，有興趣的可以仔細(xì)測(cè)試測(cè)試！
一般數(shù)據(jù)庫(kù)緩存在我看來(lái)包含四種。
第一種：?jiǎn)蝹€(gè)對(duì)象的緩存（一個(gè)對(duì)象就是數(shù)據(jù)庫(kù)一行記錄），對(duì)于單個(gè)對(duì)象的緩存，用HashMap就可以了，稍微復(fù)雜一點(diǎn)用LRU算法包裝一個(gè)HashMap，再?gòu)?fù)雜一點(diǎn)的分布式用memcached即可，沒什么太難的；
第二種：列表緩存，就像論壇里帖子的列表；
第三種：長(zhǎng)度的緩存，比如一個(gè)論壇板塊里有多少個(gè)帖子，這樣才方便實(shí)現(xiàn)分頁(yè)。
第四種：復(fù)雜一點(diǎn)的group，sum，count查詢，比如一個(gè)論壇里按點(diǎn)擊數(shù)排名的最HOT的帖子列表。
第一種比較好實(shí)現(xiàn)，后面三種比較困難，似乎沒有通用的解決辦法，我暫時(shí)以列表緩存（第二種）為例分析。
MySQL和hibernate的底層在做通用的列表緩存時(shí)都是根據(jù)查詢條件把列表結(jié)果緩存起來(lái)，但是只要該表的記錄有任何變化（增加/刪除/修改），列表緩存要全部清除，這樣只要一個(gè)表的記錄經(jīng)常變化（通常情況都會(huì)這樣），列表緩存幾乎失效，命中率太低了。
本人想了一個(gè)辦法改善了列表緩存，當(dāng)表的記錄有改變時(shí)，遍歷所有列表緩存，只有那些被影響到的列表緩存才會(huì)被刪除，而不是直接清除所有列表緩存，比如在一個(gè)論壇版（id=1）里增加了一個(gè)帖子，那么只要清除id=1這個(gè)版對(duì)應(yīng)的列表緩存就可以了，版id=2就不用清除了。這樣處理有個(gè)好處，可以緩存各種查詢條件（如等于、大于、不等于、小于）的列表緩存，但也有個(gè)潛在的性能問題，由于需要遍歷，CPU符合比較大，如果列表緩存最大長(zhǎng)度設(shè)置成10000，兩個(gè)4核的CPU每秒也只能遍歷完300多次，這樣如果每秒有超過(guò)300個(gè)insert/update/delete，系統(tǒng)就吃不消了。
在前面兩種解決辦法都不完美的情況下，本人和同事經(jīng)過(guò)幾個(gè)星期的思索，總算得出了根據(jù)表的某幾個(gè)字段做散列的緩存辦法，這種辦法無(wú)需大規(guī)模遍歷，所以 CPU符合非常小，由于這種列表緩存按照字段做了散列，所以命中率極高。思路如下：每個(gè)表有3個(gè)緩存Map（key=value鍵值對(duì)），第一個(gè)Map是對(duì)象緩存A，在A中，key是數(shù)據(jù)庫(kù)的id，Value是數(shù)據(jù)庫(kù)對(duì)象（也就是一行數(shù)據(jù)）；第二個(gè)Map是通用列表緩存B，B的最大長(zhǎng)度一般1000左右，在B中，key是查詢條件拼出來(lái)的String（如start=0,length=15#active=0#state=0），Value是該條件查詢下的所有id組成的List；第三個(gè)Map是散列緩存C，在C中，key是散列的字段（如根據(jù)userId散列的話，其中某個(gè)key就是 userId=109這樣的String）組成的String，value是一個(gè)和B類似的HashMap。其中只有B這個(gè)Map是需要遍歷的，不知道說(shuō)明白了沒有，看完小面這個(gè)例子應(yīng)該就明白了，就用論壇的回復(fù)表作說(shuō)明，假設(shè)回復(fù)表T中假設(shè)有字段id，topicId，postUserId等字段（topicId就是帖子的id，postUserId是發(fā)布者id）。
第一種情況，也是最常用的情況，就是獲取一個(gè)帖子對(duì)應(yīng)的回復(fù)，sql語(yǔ)句應(yīng)該是象
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做散列是最好的，把上面三個(gè)列表緩存（可以是N個(gè)）都散列到key是topicId=2008這一個(gè)Map 中，當(dāng)id是2008的帖子有新的回復(fù)時(shí)，系統(tǒng)自動(dòng)把key是topicId=2008的散列Map清除即可。由于這種散列不需要遍歷，因此可以設(shè)置成很大，例如100000，這樣10萬(wàn)個(gè)帖子對(duì)應(yīng)的所有回復(fù)列表都可以緩存起來(lái)，當(dāng)有一個(gè)帖子有新的回復(fù)時(shí)，其余99999個(gè)帖子對(duì)應(yīng)的回復(fù)列表都不會(huì)動(dòng)，緩存的命中率極高。
第二種情況，就是后臺(tái)需要顯示最新的回復(fù)，sql語(yǔ)句應(yīng)該是象
select id from T order by createTime desc limit 0,50
的樣子，這種情況不需要散列，因?yàn)楹笈_(tái)不可能有太多人訪問，常用列表也不會(huì)太多，所以直接放到通用列表緩存B中即可。
第三種情況，獲取一個(gè)用戶的回復(fù)，sql語(yǔ)句象
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做散列即可。
第四種情況，獲取一個(gè)用戶對(duì)某個(gè)帖子的回復(fù)，sql語(yǔ)句象
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為準(zhǔn)，也放到key是topicId=2008這個(gè)散列Map里即可。
那么最后的緩存結(jié)構(gòu)應(yīng)該是下面這個(gè)樣子：
緩存A是：
Key鍵（long型） Value值（類型T）
11 Id=11的T對(duì)象
22 Id=22的T對(duì)象
133 Id=133的T對(duì)象
……
列表緩存B是：
Key鍵（String型） Value值（ArrayList型）
from T order by createTime desc limit 0,50 ArrayList，對(duì)應(yīng)取出來(lái)的所有id
from T order by createTime desc limit 50,50 ArrayList，對(duì)應(yīng)取出來(lái)的所有id
from T order by createTime desc limit 100,50 ArrayList，對(duì)應(yīng)取出來(lái)的所有id
……
散列緩存C是：
Key鍵（String型） Value值（HashMap）
userId=2046 Key鍵（String型） Value值（ArrayList）
userId=2046#0,5 id組成的List
userId=2046#5,5 id組成的List
userId=2046#15,5 id組成的List
……
userId=2047 Key鍵（String型） Value值（ArrayList）
userId=2047#0,5 id組成的List
userId=2047#5,5 id組成的List
userId=2047#15,5 id組成的List
……
userId=2048 Key鍵（String型） Value值（ArrayList）
userId=2048#topicId=2008#0,5 id組成的List
userId=2048#5,5 id組成的List
userId=2048#15,5 id組成的List
……
……
總結(jié)：這種緩存思路可以存儲(chǔ)大規(guī)模的列表，緩存命中率極高，因此可以承受超大規(guī)模的應(yīng)用，但是需要技術(shù)人員根據(jù)自身業(yè)務(wù)邏輯來(lái)配置需要做散列的字段，一般用一個(gè)表的索引鍵做散列（注意順序，最散的字段放前面），假設(shè)以u(píng)serId為例，可以存儲(chǔ)N個(gè)用戶的M種列表，如果某個(gè)用戶的相關(guān)數(shù)據(jù)發(fā)生變化，其余 N-1個(gè)用戶的列表緩存紋絲不動(dòng)。以上說(shuō)明的都是如何緩存列表，緩存長(zhǎng)度和緩存列表思路完全一樣，如緩存象select count(*) from T where topicId=2008這樣的長(zhǎng)度，也是放到topicId=2008這個(gè)散列Map中。如果再配合好使用mysql的內(nèi)存表和memcached，加上F5設(shè)備做分布式負(fù)載均衡，該系統(tǒng)對(duì)付像1000萬(wàn)IP/天這種規(guī)模級(jí)的應(yīng)用都足夠了，除搜索引擎外一般的應(yīng)用網(wǎng)站到不了這種規(guī)模。
聯(lián)系客服
