程式設計技術快取寫法(二)

上次主要討論快取讀寫這塊各種程式碼實作。本篇是就上次的問題接著來，繼續看那些年我們各種快取用法。

一：快取預熱

上次有同學問過。在第一次載入時，我們的快取都為空，怎麼進行預熱。

單機Web情況下，一般我們使用RunTimeCache。相對於這種情況：

1：我們可以在啟動事件裡面刷新

void Application_Start(object sender, EventArgs e)
{
       //刷新
}

2：單寫個刷新快取頁面，上線後手動刷新下、或發佈時自動調用刷新、或乾脆由用戶自行觸發。

分散式快取(Redis、memcached)情況下：

例如：在幾十台伺服器快取時，單刷滿快取都需要不少一段時間。

這種預熱就複雜一些，有的會單一寫個應用程式去跑，也有的會單一寫套框架機制去處理(更智能化)。

目的都是在上線之前：所有的快取都預先載入完畢。

二：多層快取

2.1 介紹

我們曉得在CPU和記憶體之間一般都配有一級快取、二級快取來增加交換速度。

這樣當CPU調用大量資料時，就可避開記憶體直接從CPU快取中調用，加快讀取速度。

根據CPU快取得出多層級快取的特性：

1：每一級快取中儲存的是下一層快取的一部分。

2：讀取速度依等級依序遞減，成本也依序遞減，容量依序遞增。

3：當前等級未命中時，才會去下一級尋找。

而在企業應用級開發中，使用多層快取是同樣的目的及設計，只是粒度更粗，更靈活。

依速度依序排列lv1-lv6的快取類型圖：

3級快取的命中流程圖範例：

2.2 執行緒

2.2 執行緒

對於一些公共資源我們必須考慮線程安全，我們必須透過鎖來保證資料的完整性和正確性。

在實際當中，一台web伺服器至少也要處理成百上千的請求。想一想，在業務複雜的處理流程，函數每呼叫一次我們就得鎖好。

對伺服器也是個不小的浪費。而透過線程緩存，可以讓目前處理用戶請求的線程只拿自己需要的。

public static ThreadLocal<UserScore> localUserInfo = new ThreadLocal<UserScore>();

借助Net提供的線程本地變量，我們可以在請求入口去拉取當前用戶的資料。

在之後線程整個生命週期裡面，我們的業務邏輯可以毫無顧慮的使用這些數據，不需要考慮線程安全。

而且我們不用重新拿新數據，所以也不用擔心數據撕裂的問題。

因為目前執行緒週期裡面的資料是完整無誤的，而只有使用者第二次發起請求才會重新去拿新資料。 🎜🎜這樣就能提高不少我們伺服器吞吐量。注意要在執行緒出口銷毀資料。 🎜🎜2.3 記憶體快取🎜

無論是遠端資料庫讀取，還是快取伺服器讀取。避免不了要跨進程，跨網路通信，有的還跨機房。

而應用程式頻繁讀寫，對Web、DB伺服器都是個不小的消耗，速度相較記憶體也慢的多。

程式碼上加鎖、非同步，甚至加伺服器在內，都不是一個很好的辦法。因為載入速度，對使用者體驗非常重要。

所以在有要求的項目中使用本地內存做二級緩存，是非常必要的。目的是1：抗並發，2：加快讀取速度。

有個著名的快取五分鐘法則法則，就是說如果一個資料頻繁被訪問，那麼就應該放記憶體中。

舉個例子： 有100並發過來，加鎖會導致前端99線程等候，這個99線程等候著，其實是一直在消耗Web伺服器資源。不加就是緩存雪崩。

如果我們每分鐘拉取一份緩存，緩存到內存，這樣99線程等候時間極大縮短。

2.4 檔案快取

相對於內存，硬碟容量大，速度相較於走網路還更快。

所以我們完全可以把一些不常變更，放在記憶體又比較浪費的資料快取到本地硬碟。

例如使用sqlite一些檔案資料庫，我們很容易做到。

2.5 分散式快取

基於記憶體快取的redis、memcached等。

基於文件nosql的Casssandra、mongodb等。

redis、memcached是主流的分散式記憶體緩存，也是應用程式和DB中間最大的快取層。

nosql這類的其實不單單只是做快取用了，完全用在一些非核心業務的DB層了。

2.6 DB快取

這一層DB主要是快取由原始資料計算出來的結果。而避免由Web程式透過SQL或在使用上直接計算。

當然我們也可以把計算好的數據，儲存到redis做快取。

三：多層快取

多層快取概念在很多地方都用過：

1：上面我們說的多層快取就是一種，把內容依照讀取頻率等級，分不同的層次存儲，頻率越高越近。

2：也一種多層是快取索引的做法，類B樹查找，這樣能提高檢索效率。

3：從架構上來說客戶端緩存，CDN緩存，反向代理緩存，服務端緩存，也是多層緩存。

四：總結

在使用上，大家依照實際場景，進行各種組合搭配。本篇談的比較理論些，很多內容細節沒展開。

例如分散式快取使用，快取置換策略及演算法，快取過期機制等。後面會繼續補充下去。