大家已經看到很多關於Asp.Net緩存的文章了。所以我寫的時候要改變一下思路，從緩沖寫數據開始說起。緩沖寫數據的意思是在數據需要更新時不馬上把數據存到數據庫，而是先緩沖一下，然後在適當的時機再寫入到數據庫中。
緩沖寫數據可以避免在網站並發訪問多的時候，數據庫瞬間承受過大壓力，而造成死鎖或響應不及時的情況。
那麼什麼時候適合緩沖寫呢？是不是所有情況都適用呢？緩沖寫會導致數據在內存中或者web server硬盤或者第三方存儲中駐留一段時間，在這段時間內如果從數據庫中查詢最新數據的話，會有遺漏。大多數事物都有兩面性，我們需要學會趨利避害；換句話說在保證緩沖寫不會導致用戶感覺數據缺少的情況下，或者在使用適當措施不讓用戶感覺數據缺失的情況下就可以使用緩沖寫。我有兩個具體的實例來介紹如何使用緩沖寫：
1. Pv(頁面浏覽量)統計，大多數網站都有這個功能，有些網站還專門做這個服務
網站每有一個頁面被浏覽時，就會需要給對應頁面的Pv+1；這種情況下，如果直接更新到數據庫中，訪問量稍微大一些就會造成數據庫壓力過大的問題。
所以我們需要對Pv計數做緩沖，在單web server的情況下我們可以在內存中維護一個hashtable，然後用一個異步的線程去定時掃描這個hashtable，當點擊數達到“一定數字”時更新到數據庫。聽上去很簡單，不過也需要一個小技巧，上一句話中說的“一定數字”四個字不能是隨便的一個數字，如果它是4，試想一下會出現什麼情況，我們的所有Pv數都會是4的倍數，用戶會懷疑我們是不是在Pv上造假了；我們沒有造假卻留下了造假的跡象！這個“一定數字”必須是一個素數，我們可以取7，也可以用13，如果我們的訪問量很大也可以取23或31；這樣就不會出現“造假的跡象”了。
2. 發送站內短消息
站內短消息也是一個比較通用的模塊，他可以說是一種離線消息，並非im即時消息，所以我們可以利用這個業務特性， 來對發消息做下緩沖。當有短消息發送時我們可以先將這個短消息放到硬盤文件中，然後很快的響應用戶，在ui上告訴用戶，你的消息已經發出去了，然後我們可以用另一個線程（或者做一個windows服務）去監視緩沖短消息的目錄順序的將短消息存儲到數據庫中。
以上兩個場景都是比較經典的利用緩沖寫的例子，在現實中需要我們去具體分析業務和某個業務是否會造成數據庫壓力來決定是否緩沖寫，如果業務本身對數據庫的壓力就很小，那當然就沒必要考慮了，反之如果業務壓力較大我們就需要做一些工作避免緩沖寫的問題並利用緩沖寫。
請尊重作者的勞動，轉載請保留鏈接 玉開的技術博客
