您好,登錄后才能下訂單哦!
為了方便演示,這里使用Runtime.Cache做緩存容器,并定義個簡單操作類。如下:
<pre class="brush:csharp;gutter:true;"
style="margin: 0px;
padding: 0px;
white-space: pre-wrap;
overflow-wrap: break-word;">
public class CacheHelper
{
public static object Get(string cacheKey)
{
return HttpRuntime.Cache[cacheKey];
}
public static void Add(string cacheKey, object obj, int cacheMinute)
{
HttpRuntime.Cache.Insert(cacheKey, obj, null, DateTime.Now.AddMinutes(cacheMinute),
Cache.NoSlidingExpiration, CacheItemPriority.Normal, null);
}
}
</pre>
?簡單讀取:
<pre class="brush:csharp;
gutter:true;
" style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
">
public object GetMemberSigninDays1() {
const int cacheTime = 5;
const string cacheKey = "mushroomsir";
var cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null)
return cacheValue;
cacheValue = "395";
//這里一般是 sql查詢數據。 例:395 簽到天數
CacheHelper.Add(cacheKey,cacheValue,cacheTime);
return cacheValue;
}
</pre>
在項目中,有不少這樣寫法,這樣寫并沒有錯,但在并發量上來后就容易出問題。
緩存雪崩是由于緩存失效(過期),新緩存未到期間。
這個中間時間內,所有請求都去查詢數據庫,而對數據庫CPU和內存造成巨大壓力,前端連接數不夠、查詢阻塞。
這個中間時間并沒有那么短,比如sql查詢1秒,加上傳輸解析0.5秒。 ?就是說1.5秒內所有用戶查詢,都是直接查詢數據庫的。
碰到這種情況,使用最多的解決方案就是加鎖排隊。
<pre style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
font-family:"
Courier New"
!important;
font-size:12px !important;
">
public static object obj1 = new object();
public object GetMemberSigninDays2() {
const int cacheTime = 5;
const string cacheKey = "mushroomsir";
var cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) return cacheValue;
//lock (obj1) //全局鎖 // {
// cacheValue = CacheHelper.Get(cacheKey);
// if (cacheValue != null) // return cacheValue;
// cacheValue = "395";
//這里一般是 sql查詢數據。 例:395 簽到天數 // CacheHelper.Add(cacheKey,cacheValue,cacheTime);
//
}
lock (this) {
cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) return cacheValue;
cacheValue = "395";
//這里一般是 sql查詢數據。 例:395 簽到天數
CacheHelper.Add(cacheKey,cacheValue,cacheTime);
}
return cacheValue;}</pre>
第一種:lock (obj1)??是全局鎖可以滿足,但要為每個函數都聲明一個obj,不然在A、B函數都鎖obj1時,必然會讓其中一個阻塞。
第二種:lock (this) ?這個鎖當前實例,對其他實例無效,那這個鎖就沒什么效果了,當然使用單例模式的對象可以鎖。
?在當前實例中:A函數鎖當前實例,其他也鎖當前實例的函數的讀寫,也被阻塞,這種做法也不可取。
既然鎖對象不行,利用字符串的特性,直接鎖緩存的key呢
<pre style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
font-family:"
Courier New"
!important;
font-size:12px !important;
">
public object GetMemberSigninDays3() {
const int cacheTime = 5;
const string cacheKey = "mushroomsir";
var cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) return cacheValue;
const string lockKey = cacheKey + "n(*≧▽≦*)n";
//lock (cacheKey) // {
// cacheValue = CacheHelper.Get(cacheKey);
// if (cacheValue != null) // return cacheValue;
// cacheValue = "395";
//這里一般是 sql查詢數據。 例:395 簽到天數 // CacheHelper.Add(cacheKey,cacheValue,cacheTime);
//
}
lock (lockKey) {
cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) return cacheValue;
cacheValue = "395";
//這里一般是 sql查詢數據。 例:395 簽到天數
CacheHelper.Add(cacheKey,cacheValue,cacheTime);
}
return cacheValue;}
</pre>
第一種:lock (cacheName)??有問題,因為字符串也是共享的,會阻塞其他使用這個字符串的操作行為。 ?
因為字符串被公共語言運行庫 (CLR)暫留,這意味著整個程序中任何給定字符串都只有一個實例,所以才會用下面第二種方法。
第二種:lock (lockKey) ?可以滿足。其目的就是為了保證鎖的粒度最小并且全局唯一性,只鎖當前緩存的查詢行為。
先舉個簡單例子:一般網站經常會緩存用戶搜索的結果,如果數據庫查詢不到,是不會做緩存的。但如果頻繁查這個空關鍵字,會導致每次請求都直接查詢數據庫了。
例子就是緩存穿透,請求繞過緩存直接查數據庫,這也是經常提的緩存命中率問題。
<pre style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
font-family:"
Courier New"
!important;
font-size:12px !important;
">
public object GetMemberSigninDays4() {
const int cacheTime = 5;
const string cacheKey = "mushroomsir";
var cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) return cacheValue;
const string lockKey = cacheKey + "n(*≧▽≦*)n";
lock (lockKey) {
cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null) return cacheValue;
cacheValue = null;
//數據庫查詢不到,為空。 //if (cacheValue2 == null) // {
// return null;
//一般為空,不做緩存 //
}
if (cacheValue == null) {
cacheValue = string.Empty;
//如果發現為空,我設置個默認值,也緩存起來。
}
CacheHelper.Add(cacheKey,cacheValue,cacheTime);}return cacheValue;}</pre>
如果把查詢不到的空結果,也給緩存起來,這樣下次同樣的請求就可以直接返回null了,即可以避免當查詢的值為空時引起的緩存穿透。
可以單獨設置個緩存區域存儲空值,對要查詢的key進行預先校驗,然后再放行給后面的正常緩存處理邏輯。
前面不是用加鎖排隊方式就解決了嗎?其實加鎖排隊只是為了減輕數據庫的壓力,本質上并沒有提高系統吞吐量。
假設在高并發下,緩存重建期間key是鎖著的,這是過來1000個請求999個都在阻塞的。導致的結果是用戶等待超時,這是非常不優化的體驗。
這種行為本質上是把多線程的Web服務器,在此時給變成單線程處理了,會導致大量的阻塞。對于系統資源也是一種浪費,因緩存重建而阻塞的線程本可以處理更多請求的。
這里提出一種解決方案是:
<pre style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
font-family:"
Courier New"
!important;
font-size:12px !important;
">
public object GetMemberSigninDays5() {
const int cacheTime = 5;
const string cacheKey = "mushroomsir";
//緩存標記。
const string cacheSign = cacheKey + "_Sign";
var sign = CacheHelper.Get(cacheSign);
//獲取緩存值
var cacheValue = CacheHelper.Get(cacheKey);
if (sign != null) return cacheValue;
//未過期,直接返回。
lock (cacheSign) {
sign = CacheHelper.Get(cacheSign);
if (sign != null) return cacheValue;
CacheHelper.Add(cacheSign,"1",cacheTime);
ThreadPool.QueueUserWorkItem((arg) => {
cacheValue = "395";
//這里一般是 sql查詢數據。 例:395 簽到天數
CacheHelper.Add(cacheKey,cacheValue,cacheTime*2);
//日期設緩存時間的2倍,用于臟讀。
}
);}return cacheValue;}
</pre>
從代碼中看出,我們多使用了一個緩存標記key,并使用雙檢鎖校驗保證后面邏輯不會多次執行。
緩存標記key: 緩存標記key只是一個記錄實際key過期時間的標記,它的緩存值可以是任意值,比如1。 它主要用來在實際key過期后,觸發通知另外的線程在后臺去更新實際key的緩存。
實際key: ?它的過期時間會延長1倍,例:本來5分鐘,現在設置為10分鐘。 這樣做的目的是,當緩存標記key過期后,實際緩存還能以臟數據返回給調用端,直到另外的線程在后臺更新完成后,才會返回新緩存。
關于實際key的過期時間延長1倍,還是2、3倍都是可以的。只要大于正常緩存過期時間,并且能保證在延長的時間內足夠拉取數據即可。
還一個好處就是,如果突然db掛了,臟數據的存在可以保證前端系統不會拿不到數據。
這樣做后,就可以一定程度上提高系統吞吐量。
文中說的阻塞其他函數指的是,并發情況下鎖同一對象,比如一個函數鎖A對象,另外的函數就必須等待A對象的鎖釋放后才能再次進鎖。
關于更新緩存,可以單開一個線程去專門跑緩存更新,圖方便的話扔線程池里面即可。
實際項目中,緩存層框架的封裝往往要復雜的多,如果并發量比較小,這樣寫反而會增加代碼的復雜度,具體要根據實際情況來取舍。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。