最近常有廈門的客戶通過網(wǎng)站上的聯(lián)系我，詢問網(wǎng)站改版的情況。幾乎每日都要針對(duì)客戶網(wǎng)站存在的問題做一番分析，然后客戶以價(jià)格等其他因素結(jié)束對(duì)話，如此反復(fù)，實(shí)在煩人。

　　為此做一個(gè)內(nèi)容整理，希望很多只是想了解或者參考資料而不準(zhǔn)備花錢改版的客戶也不枉此行吧。言歸正傳。

　　一般客戶要求對(duì)網(wǎng)站改版，無非存在以下原因：

　　對(duì)網(wǎng)站美工不滿意;

　　對(duì)網(wǎng)站框架(欄目)結(jié)構(gòu)不滿意;

　　對(duì)網(wǎng)站在搜索引擎的排名不滿意，希望做一些優(yōu)化;

　　網(wǎng)站年久失修，沒人回復(fù)，需要徹底重做。。。

　　大凡有此需求的客戶，都應(yīng)該值得贊許，至少他們已經(jīng)認(rèn)可了網(wǎng)絡(luò)可以為他們帶來一定的信息幫助。同時(shí)他們應(yīng)該也從網(wǎng)絡(luò)中反饋到很多信息，因此才希望對(duì)自身網(wǎng)站進(jìn)行升級(jí)改版。

　　根據(jù)與客戶的溝通得出，一般網(wǎng)站改版包含四個(gè)部分：

　　網(wǎng)站整體風(fēng)格改版(美工);

　　網(wǎng)站內(nèi)部代碼程序重寫(程序);

　　以上二者兼顧;

　　網(wǎng)站優(yōu)化，包括搜索引擎優(yōu)化及網(wǎng)站內(nèi)部?jī)?yōu)化更易瀏覽。要做到這些，所以都必須以用戶體驗(yàn)為最終目標(biāo)。網(wǎng)站不是我們的客戶說怎么樣就怎么樣的，而應(yīng)該是給最終瀏覽者去體驗(yàn)的，也就是說改版過的網(wǎng)站應(yīng)該更容易被搜索到，更容易訪問，更容易使用(訪客使用和網(wǎng)站管理員使用)。

　　那么首先{dy}步，應(yīng)該詢問我們的客戶對(duì)目前網(wǎng)站不滿意的地方，成都網(wǎng)絡(luò)推廣以及他們的客戶反饋過來的信息;然后，我們對(duì)客戶的網(wǎng)站進(jìn)行剖析，將存在的問題以圖表的形式羅列出來;提出我們的解決方案，與客戶探討。然后就是報(bào)價(jià)。

　　至于第二、第三步，很多客戶都會(huì)要求你越詳細(xì)越好。而{dy}步呢，客戶有時(shí)候不愿意說出來或者他根本說不出來。因此需要我們?nèi)ヒ龑?dǎo)客戶。然而到了第四步，就很tt，很多客戶，他們更關(guān)心價(jià)格，或者說他們最希望的價(jià)格越低越好，然后才是效果問題。所以，現(xiàn)在都不是很愿意去回答第二、第三個(gè)問題了?？赡苓@個(gè)也是個(gè)人業(yè)務(wù)能力的問題吧?？傊芏嗫蛻魰?huì)說，

　　“你的見解很好，我們會(huì)很中肯的去接受，但是你的價(jià)格我們沒辦法接受，還是很感謝你的!”

這兩天發(fā)現(xiàn)我運(yùn)營(yíng)的一個(gè)門戶網(wǎng)站出現(xiàn)了數(shù)據(jù)無法寫入的問題，新會(huì)員不能注冊(cè)，信息不能發(fā)布，不能正常登陸會(huì)員系統(tǒng)，實(shí)在找不到原因，覺定還原備份數(shù)據(jù)庫，但在恢復(fù)mssql數(shù)據(jù)庫過程過程中，提示數(shù)據(jù)庫日志滿已滿，請(qǐng)清空數(shù)據(jù)庫日志后，還原。我想可能就是這個(gè)原因?qū)е聰?shù)據(jù)不能正常的寫入，然后就baidu搜索了相關(guān)的信息，終于找到了原因，程序運(yùn)行完，修復(fù)成功，今天把源代碼公布出來，希望對(duì)大家有所幫助，大家以后出現(xiàn)相似問題不防也采有清空數(shù)據(jù)庫日志的方法,可以也會(huì)解決相似問題，清空數(shù)據(jù)庫日志不會(huì)對(duì)服務(wù)器數(shù)據(jù)有所損害，能解決數(shù)據(jù)庫不能寫入的原因，代碼如下：　　

系統(tǒng)主要是構(gòu)建在hibernate之上的高效數(shù)據(jù)庫緩存系統(tǒng)，其中包含了分布式解決方案，該系統(tǒng)已經(jīng)應(yīng)用在舍得網(wǎng)上了，沒有發(fā)現(xiàn)大問題，本人也相信該系統(tǒng)已經(jīng)足夠強(qiáng)大，應(yīng)付數(shù)百萬IP/天的應(yīng)用都不是問題。

　　代碼看上去很簡(jiǎn)單，其實(shí)卻是兩年經(jīng)驗(yàn)的總結(jié)，整過過程也遇到了很多難點(diǎn)，{zh1}一一解決了。本系統(tǒng)非常簡(jiǎn)潔易用，主程序BaseManager.java不到1000行代碼，用“精悍”來形容{jd1}不為過，1000行代碼卻包含了數(shù)據(jù)庫對(duì)象的緩存、列表和長(zhǎng)度的緩存、按字段散列緩存、update延時(shí)更新、自動(dòng)qc列表緩存等功能，用它來實(shí)現(xiàn)像論壇、博客、校友錄、交友社區(qū)等絕大部分應(yīng)用網(wǎng)站都足夠了。

　　現(xiàn)在進(jìn)入正題。。。。。

　　為什么要用緩存?如果問這個(gè)問題說明你還是新手，數(shù)據(jù)庫吞吐量畢竟有限，每秒讀寫5000次了不起了，如果不用緩存，假設(shè)一個(gè)頁面有100個(gè)數(shù)據(jù)庫操作，50個(gè)用戶并發(fā)數(shù)據(jù)庫就歇菜，這樣最多能支撐的pv也就50*3600*15=270萬，而且數(shù)據(jù)庫服務(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í)行上百萬次put和get，在這上面損耗的性能幾乎可以忽略不記了。溫馨提示：能不用分布式的時(shí)候就不要用分布式，非用分布式的時(shí)候再考慮用memcached，我的緩存系統(tǒng)在這方面都已經(jīng)實(shí)現(xiàn)了，改個(gè)配置就可以了，有興趣的可以仔細(xì)測(cè)試測(cè)試!

　　一般數(shù)據(jù)庫緩存在我看來包含四種。{dy}種：?jiǎn)蝹€(gè)對(duì)象的緩存(一個(gè)對(duì)象就是數(shù)據(jù)庫一行記錄)，對(duì)于單個(gè)對(duì)象的緩存，用HashMap就可以了，稍微復(fù)雜一點(diǎn)用LRU算法包裝一個(gè)HashMap，再?gòu)?fù)雜一點(diǎn)的分布式用memcached即可，沒什么太難的;第二種：列表緩存，就像論壇里帖子的列表;第三種：長(zhǎng)度的緩存，比如一個(gè)論壇板塊里有多少個(gè)帖子，這樣才方便實(shí)現(xiàn)分頁。第四種：復(fù)雜一點(diǎn)的group，sum，count查詢，比如一個(gè)論壇里按點(diǎn)擊數(shù)排名的最HOT的帖子列表。{dy}種比較好實(shí)現(xiàn)，后面三種比較困難，似乎沒有通用的解決辦法，我暫時(shí)以列表緩存(第二種)為例分析。

　　mysql和hibernate的底層在做通用的列表緩存時(shí)都是根據(jù)查詢條件把列表結(jié)果緩存起來，但是只要該表的記錄有任何變化(增加/刪除/修改)，列表緩存要全部qc，這樣只要一個(gè)表的記錄經(jīng)常變化(通常情況都會(huì)這樣)，列表緩存幾乎失效，命中率太低了。

　　本人想了一個(gè)辦法改善了列表緩存，當(dāng)表的記錄有改變時(shí)，遍歷所有列表緩存，只有那些被影響到的列表緩存才會(huì)被刪除，而不是直接qc所有列表緩存，比如在一個(gè)論壇版(id=1)里增加了一個(gè)帖子，那么只要qcid=1這個(gè)版對(duì)應(yīng)的列表緩存就可以了，版id=2就不用qc了。這樣處理有個(gè)好處，可以緩存各種查詢條件(如等于、大于、不等于、小于)的列表緩存，但也有個(gè)潛在的性能問題，由于需要遍歷，CPU符合比較大，如果列表緩存{zd0}長(zhǎng)度設(shè)置成10000，兩個(gè)4核的CPU每秒也只能遍歷完300多次，這樣如果每秒有超過300個(gè)insert/update/delete，系統(tǒng)就吃不消了，此路不通。

　　在前面兩種解決辦法都不wm的情況下，本人和同事經(jīng)過幾個(gè)星期的思索，總算得出了根據(jù)表的某幾個(gè)字段做散列的緩存辦法，這種辦法無需大規(guī)模遍歷，所以CPU符合非常小，由于這種列表緩存按照字段做了散列，所以命中率極高。思路如下：每個(gè)表有3個(gè)緩存Map(key=value鍵值對(duì))，{dy}個(gè)Map是對(duì)象緩存A，在A中，key是數(shù)據(jù)庫的id，Value是數(shù)據(jù)庫對(duì)象(也就是一行數(shù)據(jù));第二個(gè)Map是通用列表緩存B，B的{zd0}長(zhǎng)度一般1000左右，在B中，key是查詢條件拼出來的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是需要遍歷的，不知道說明白了沒有，看完小面這個(gè)例子應(yīng)該就明白了，就用論壇的回復(fù)表作說明，假設(shè)回復(fù)表T中假設(shè)有字段id，topicId，postUserId等字段(topicId就是帖子的id，postUserId是發(fā)布者id)。

　　{dy}種情況，也是最常用的情況，就是獲取一個(gè)帖子對(duì)應(yīng)的回復(fù)，sql語句應(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做散列是{zh0}的，把上面三個(gè)列表緩存(可以是N個(gè))都散列到key是topicId=2008這一個(gè)Map中，當(dāng)id是2008的帖子有新的回復(fù)時(shí)，系統(tǒng)自動(dòng)把key是topicId=2008的散列Mapqc即可。由于這種散列不需要遍歷，因此可以設(shè)置成很大，例如100000，這樣10萬個(gè)帖子對(duì)應(yīng)的所有回復(fù)列表都可以緩存起來，當(dāng)有一個(gè)帖子有新的回復(fù)時(shí)，其余99999個(gè)帖子對(duì)應(yīng)的回復(fù)列表都不會(huì)動(dòng)，緩存的命中率極高。

　　第二種情況，就是后臺(tái)需要顯示{zx1}的回復(fù)，sql語句應(yīng)該是象

　　select id from T order by createTime desc limit 0,50

　　的樣子，這種情況不需要散列，因?yàn)楹笈_(tái)不可能有太多人訪問，常用列表也不會(huì)太多，所以直接放到通用列表緩存B中即可。

　　第三種情況，獲取一個(gè)用戶的回復(fù)，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

　　的樣子，那么這種列表和{dy}種情況類似，用userId做散列即可。

　　第四種情況，獲取一個(gè)用戶對(duì)某個(gè)帖子的回復(fù)，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為準(zhǔn)，也放到key是topicId=2008這個(gè)散列Map里即可。

　　那么{zh1}的緩存結(jié)構(gòu)應(yīng)該是下面這個(gè)樣子：

　　緩存A是：

　　Key鍵(long型)Value值(類型T)

　　11Id=11的T對(duì)象

　　22Id=22的T對(duì)象

　　133Id=133的T對(duì)象

　　……

　　列表緩存B是：

　　Key鍵(String型)Value值(ArrayList型)

　　from T order by createTime desc limit 0,50ArrayList，對(duì)應(yīng)取出來的所有id

　　from T order by createTime desc limit 50,50ArrayList，對(duì)應(yīng)取出來的所有id

　　from T order by createTime desc limit 100,50ArrayList，對(duì)應(yīng)取出來的所有id

　　……

　　散列緩存C是：

　　Key鍵(String型)Value值(HashMap)

　　userId=2046Key鍵(String型)Value值(ArrayList)

　　userId=2046#0,5id組成的List

　　userId=2046#5,5id組成的List

　　userId=2046#15,5id組成的List

　　……

　　userId=2047Key鍵(String型)Value值(ArrayList)

　　userId=2047#0,5id組成的List

　　userId=2047#5,5id組成的List

　　userId=2047#15,5id組成的List

　　……

　　userId=2048Key鍵(String型)Value值(ArrayList)

　　userId=2048#topicId=2008#0,5id組成的List

　　userId=2048#5,5id組成的List

　　userId=2048#15,5id組成的List

　　……

　　……

　　總結(jié)：這種緩存思路可以存儲(chǔ)大規(guī)模的列表，緩存命中率極高，因此可以承受超大規(guī)模的應(yīng)用，但是需要技術(shù)人員根據(jù)自身業(yè)務(wù)邏輯來配置需要做散列的字段，一般用一個(gè)表的索引鍵做散列(注意順序，最散的字段放前面)，假設(shè)以u(píng)serId為例，可以存儲(chǔ)N個(gè)用戶的M種列表，如果某個(gè)用戶的相關(guān)數(shù)據(jù)發(fā)生變化，其余N-1個(gè)用戶的列表緩存紋絲不動(dòng)。以上說明的都是如何緩存列表，緩存長(zhǎng)度和緩存列表思路wq一樣，如緩存象select count(*) from T where topicId=2008這樣的長(zhǎng)度，也是放到topicId=2008這個(gè)散列Map中。如果再配合好使用mysql的拆表和memcached，加上F5設(shè)備做分布式負(fù)載均衡，該系統(tǒng)對(duì)付像1000萬IP/天這種規(guī)模級(jí)的應(yīng)用都足夠了。