緩存的作用其實(shí)很明確，如下兩方面：

• 提升數(shù)據(jù)的獲取速度

通常用在獲取數(shù)據(jù)速度要求比較高的場(chǎng)景，比如一些和設(shè)備通信的軟件，對(duì)時(shí)間的要求比較高，如果每次都從數(shù)據(jù)庫(kù)讀數(shù)據(jù)會(huì)導(dǎo)致消耗多余的時(shí)間。

• 減輕后臺(tái)應(yīng)用或數(shù)據(jù)庫(kù)服務(wù)器的負(fù)載

對(duì)于高并發(fā)場(chǎng)景的系統(tǒng)，如果每次請(qǐng)求都打到數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)服務(wù)器負(fù)載會(huì)變大，到達(dá)一定瓶頸之后可能讓系統(tǒng)體驗(yàn)變差或不可用。

1. 瀏覽器緩存

1.1 簡(jiǎn)述

通過控制響應(yīng)頭信息，告訴瀏覽器讓其將對(duì)應(yīng)的數(shù)據(jù)緩存到本地，在指定時(shí)間范圍內(nèi)，可直接從本地緩存中取即可，但瀏覽器方可以不選擇走緩存。

1.2 案例演示

本文中還是使用WebAPI項(xiàng)目進(jìn)行演示，只是通過不同的API來(lái)區(qū)分不同案例。

創(chuàng)建好項(xiàng)目中，在默認(rèn)的WeatherForecastController中添加一個(gè)Action方法，如下：

這個(gè)時(shí)候還沒有做緩存處理，所以只要訪問都會(huì)調(diào)用接口獲取最新的數(shù)據(jù)。

在接口方法上只需添加ResponseCache特性就可以實(shí)現(xiàn)瀏覽器緩存，如下：

這樣就可以實(shí)現(xiàn)客戶端緩存了，可能會(huì)有小伙伴會(huì)點(diǎn)擊瀏覽器的刷新和F5進(jìn)行測(cè)試，這個(gè)時(shí)候并沒有看到緩存效果，其實(shí)這個(gè)時(shí)候?yàn)g覽器是以新的請(qǐng)求發(fā)出的，并不會(huì)去緩存里取，但其實(shí)請(qǐng)求獲取到的數(shù)據(jù)已經(jīng)存緩存了。

那怎么去測(cè)試呢?每次都 打開多個(gè)瀏覽器標(biāo)簽或用Swagger的形式，如下：

第一次訪問：

每次都打開新標(biāo)簽，再訪問接口：

除了根據(jù)數(shù)據(jù)沒變來(lái)判定是緩存數(shù)據(jù)外，還可以通過請(qǐng)求確定是否從本地緩存中取數(shù)據(jù)，如下：

Swagger演示，關(guān)于如何集成Swagger，之前有專門分享過(跟我一起學(xué).NetCore之Swagger讓前后端不再煩惱及界面自定義)：

瀏覽器緩存的原理其實(shí)就是在響應(yīng)頭中增加Cache-Control(ResponseCache的方式是通過Action過濾器的形式設(shè)置的響應(yīng)頭)，告訴瀏覽器進(jìn)行數(shù)據(jù)緩存，在指定時(shí)間范圍內(nèi)可以從緩存中取，我們也可以自己手動(dòng)設(shè)置響應(yīng)頭信息來(lái)達(dá)到同樣的效果，如下：

盡管數(shù)據(jù)已經(jīng)緩存，瀏覽器也可以選擇不從緩存取，如下：

2. 服務(wù)器緩存

2.1 簡(jiǎn)述

瀏覽器緩存只是將數(shù)據(jù)保存在單臺(tái)電腦的不同位置，如果打開不同的瀏覽器或不同的電腦訪問時(shí)，還是起不到緩存的效果，所以搞個(gè)服務(wù)器緩存肯定是個(gè)不錯(cuò)的選擇。

即將數(shù)據(jù)緩存到站點(diǎn)服務(wù)器中，當(dāng)請(qǐng)求過來(lái)時(shí)，如果命中緩存，直接獲取返回即可，不調(diào)用對(duì)應(yīng)的后臺(tái)API。

2.2 案例

其實(shí)這只是在原來(lái)瀏覽器緩存的基礎(chǔ)上增加了一個(gè)中間件的處理，如下：

代碼如下：

運(yùn)行效果：

由于不同的瀏覽器保存的數(shù)據(jù)位置不一樣，如果僅僅是本地緩存，那么兩個(gè)瀏覽器的數(shù)據(jù)會(huì)返回不一樣;另外第一個(gè)瀏覽器訪問之后，其他瀏覽器在時(shí)間范圍內(nèi)獲得結(jié)果是一樣的，也不會(huì)調(diào)用后臺(tái)接口。

這種服務(wù)器端的緩存在有些情況是不生效的，如：請(qǐng)求Method不是Get或Head的不緩存，返回狀態(tài)碼不是200的不緩存，請(qǐng)求頭包含Authorization的不緩存等，所以基本很少用這種方式進(jìn)行緩存操作。

3. 應(yīng)用內(nèi)存緩存

3.1 簡(jiǎn)述

對(duì)于上面說(shuō)到的瀏覽器緩存和服務(wù)器緩存，如果是友好的用戶訪問，沒問題，能起到一定的效果;但如果有人要使壞，不設(shè)置對(duì)應(yīng)的請(qǐng)求頭訪問API(禁用緩存)，最終還是會(huì)給應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器帶來(lái)壓力。所以需要一種能主動(dòng)控制的緩存方式，后端程序就是下手的對(duì)象，在后端程序中寫緩存邏輯，這樣緩存策略就由我們自己控制了。

雖然每次請(qǐng)求都會(huì)進(jìn)入應(yīng)用程序，但會(huì)先從緩存中進(jìn)行獲取數(shù)據(jù)，如果命中緩存，就不再進(jìn)行數(shù)據(jù)庫(kù)訪問，直接將緩存數(shù)據(jù)返回。

3.2 案例

其實(shí)框架中針對(duì)內(nèi)存緩存這塊已經(jīng)做好了封裝，只需注冊(cè)相關(guān)的服務(wù)就可以用了，如下：

注冊(cè)完成之后，只需要注入就可以使用了，這里增加一個(gè)Action方法進(jìn)行演示：

效果就不截圖了，在20秒內(nèi)，單程序部署情況下，不管怎么訪問都會(huì)是一樣的結(jié)果。

4. 分布式緩存

4.1 簡(jiǎn)述

內(nèi)存緩存雖然能解決瀏覽器和服務(wù)器緩存的缺點(diǎn)，但只對(duì)單體部署程序比較適用，對(duì)于需要分布式部署的程序來(lái)說(shuō)，程序內(nèi)存之間的緩存數(shù)據(jù)不能共享，緩存的效果肯定就沒那么盡人意，所以分布式緩存就出來(lái)了，采用對(duì)應(yīng)的中間件，如Memcache、Redis等，而Redis成為了緩存的首選。

請(qǐng)求的邏輯和內(nèi)存緩存差不多一樣，只是分布式緩存會(huì)采用第三方中間件進(jìn)行數(shù)據(jù)存儲(chǔ)，保證分布式部署的程序共用一套緩存。

4.2 案例

這里還是用最火的Redis做演示，所以需要提前安裝Redis。

框架也提供了統(tǒng)一操作分布式緩存的接口IDistributedCache，用法和上面的內(nèi)存緩存基本一樣。

這里用的是Redis，所以需要安裝對(duì)應(yīng)的Nuget包Microsoft.Extensions.Caching.StackExchangeRed，然后注冊(cè)相關(guān)服務(wù)就可以用了，如下：

注冊(cè)完成之后，只需要注入就可以使用了，這里也增加一個(gè)Action方法進(jìn)行演示：

訪問對(duì)應(yīng)的接口，在設(shè)置的時(shí)間范圍內(nèi)從Redis中讀取到的數(shù)據(jù)一致，過期之后就會(huì)清空，程序又會(huì)設(shè)置新的值，如下：

關(guān)于緩存的幾種用法就先暫時(shí)說(shuō)這么多，也有小伙伴根據(jù)業(yè)務(wù)場(chǎng)景自己實(shí)現(xiàn)的。

實(shí)例的源碼：https://gitee.com/CodeZoe/dot-net-core-study-demo/tree/main/CacheDemo

總結(jié)

緩存之所以現(xiàn)在這么火，其主要目的還是提升數(shù)據(jù)訪問效率，緩解應(yīng)用和數(shù)據(jù)庫(kù)的壓力，但同時(shí)也會(huì)帶來(lái)一些問題，比如緩存穿透、緩存擊穿、緩存雪崩及緩存數(shù)據(jù)與數(shù)據(jù)庫(kù)不一致等問題，后續(xù)我們會(huì)逐個(gè)說(shuō)說(shuō)。