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

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

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

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

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

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

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

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

最新評論