大家已經(jīng)看到很多關(guān)于Asp.Net緩存的文章了。所以我寫的時(shí)候要改變一下思路，從緩沖寫數(shù)據(jù)開始說起。緩沖寫數(shù)據(jù)的意思是在數(shù)據(jù)需要更新時(shí)不馬上把數(shù)據(jù)存到數(shù)據(jù)庫，而是先緩沖一下，然后在適當(dāng)?shù)臅r(shí)機(jī)再寫入到數(shù)據(jù)庫中。

緩沖寫數(shù)據(jù)可以避免在網(wǎng)站并發(fā)訪問多的時(shí)候，數(shù)據(jù)庫瞬間承受過大壓力，而造成死鎖或響應(yīng)不及時(shí)的情況。

那么什么時(shí)候適合緩沖寫呢？是不是所有情況都適用呢？緩沖寫會(huì)導(dǎo)致數(shù)據(jù)在內(nèi)存中或者web server硬盤或者第三方存儲(chǔ)中駐留一段時(shí)間，在這段時(shí)間內(nèi)如果從數(shù)據(jù)庫中查詢最新數(shù)據(jù)的話，會(huì)有遺漏。大多數(shù)事物都有兩面性，我們需要學(xué)會(huì)趨利避害；換句話說在保證緩沖寫不會(huì)導(dǎo)致用戶感覺數(shù)據(jù)缺少的情況下，或者在使用適當(dāng)措施不讓用戶感覺數(shù)據(jù)缺失的情況下就可以使用緩沖寫。我有兩個(gè)具體的實(shí)例來介紹如何使用緩沖寫：

1. Pv(頁面瀏覽量)統(tǒng)計(jì)，大多數(shù)網(wǎng)站都有這個(gè)功能，有些網(wǎng)站還專門做這個(gè)服務(wù)
　　網(wǎng)站每有一個(gè)頁面被瀏覽時(shí)，就會(huì)需要給對(duì)應(yīng)頁面的Pv+1；這種情況下，如果直接更新到數(shù)據(jù)庫中，訪問量稍微大一些就會(huì)造成數(shù)據(jù)庫壓力過大的問題。

　　所以我們需要對(duì)Pv計(jì)數(shù)做緩沖，在單web server的情況下我們可以在內(nèi)存中維護(hù)一個(gè)hashtable，然后用一個(gè)異步的線程去定時(shí)掃描這個(gè)hashtable，當(dāng)點(diǎn)擊數(shù)達(dá)到“一定數(shù)字”時(shí)更新到數(shù)據(jù)庫。聽上去很簡單，不過也需要一個(gè)小技巧，上一句話中說的“一定數(shù)字”四個(gè)字不能是隨便的一個(gè)數(shù)字，如果它是4，試想一下會(huì)出現(xiàn)什么情況，我們的所有Pv數(shù)都會(huì)是4的倍數(shù)，用戶會(huì)懷疑我們是不是在Pv上造假了；我們沒有造假卻留下了造假的跡象！這個(gè)“一定數(shù)字”必須是一個(gè)素?cái)?shù)，我們可以取7，也可以用13，如果我們的訪問量很大也可以取23或31；這樣就不會(huì)出現(xiàn)“造假的跡象”了。

2. 發(fā)送站內(nèi)短消息
　　站內(nèi)短消息也是一個(gè)比較通用的模塊，他可以說是一種離線消息，并非im即時(shí)消息，所以我們可以利用這個(gè)業(yè)務(wù)特性，　　來對(duì)發(fā)消息做下緩沖。當(dāng)有短消息發(fā)送時(shí)我們可以先將這個(gè)短消息放到硬盤文件中，然后很快的響應(yīng)用戶，在ui上告訴用戶，你的消息已經(jīng)發(fā)出去了，然后我們可以用另一個(gè)線程（或者做一個(gè)windows服務(wù)）去監(jiān)視緩沖短消息的目錄順序的將短消息存儲(chǔ)到數(shù)據(jù)庫中。

以上兩個(gè)場(chǎng)景都是比較經(jīng)典的利用緩沖寫的例子，在現(xiàn)實(shí)中需要我們?nèi)ゾ唧w分析業(yè)務(wù)和某個(gè)業(yè)務(wù)是否會(huì)造成數(shù)據(jù)庫壓力來決定是否緩沖寫，如果業(yè)務(wù)本身對(duì)數(shù)據(jù)庫的壓力就很小，那當(dāng)然就沒必要考慮了，反之如果業(yè)務(wù)壓力較大我們就需要做一些工作避免緩沖寫的問題并利用緩沖寫。

請(qǐng)尊重作者的勞動(dòng)，轉(zhuǎn)載請(qǐng)保留鏈接 玉開的技術(shù)博客

最新評(píng)論