Asp.Net 網站效能最佳化之緩字決 （上） 緩衝寫資料

大家已經看到很多關於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服務）去監視緩衝短訊息的目錄順序的將短訊息儲存到資料庫中。

以上兩個情境都是比較經典的利用緩衝寫的例子，在現實中需要我們去具體分析業務和某個業務是否會造成資料庫壓力來決定是否緩衝寫，如果業務本身對資料庫的壓力就很小，那當然就沒必要考慮了，反之如果業務壓力較大我們就需要做一些工作避免緩衝寫的問題並利用緩衝寫。

請尊重作者的勞動，轉載請保留連結 玉開的技術部落格