您好,登錄后才能下訂單哦!
小編今天帶大家了解.NET 6開發(fā)中怎么實現(xiàn)緩存,文中知識點介紹的非常詳細。覺得有幫助的朋友可以跟著小編一起瀏覽文章的內(nèi)容,希望能夠幫助更多想解決這個問題的朋友找到問題的答案,下面跟著小編一起深入學(xué)習(xí)“.NET 6開發(fā)中怎么實現(xiàn)緩存”的知識吧。
有的時候為了減少客戶端請求相同資源的邏輯重復(fù)執(zhí)行,我們會考慮使用一些緩存的方式,在.NET 6中,我們可以借助框架提供的中間件來實現(xiàn)請求資源的緩存。
實現(xiàn)請求結(jié)果的緩存。
對于在.NET6中實現(xiàn)緩存,我們可以使用響應(yīng)緩存中間件ResponseCaching
來實現(xiàn),同時可以使用Marvin.Cache.Headers
來為我們提供更多的緩存相關(guān)的屬性。
既然是中間件,我們便在Program中引入:
Program.cs
// 省略其他... // 配置緩存中間件 builder.Services.AddResponseCaching(); builder.Services.AddControllers(); // ... // 使用緩存中間件 app.UseResponseCaching(); app.MapControllers();
在使用方法上,有幾種方式可以實現(xiàn)配置:1)進行全局的配置,應(yīng)用于所有添加了相同ProfileName
的ResponseCache
的Controller響應(yīng);2)對單個Controller/Action進行配置,應(yīng)用于當(dāng)前作用的Controller/Action;3)全局配置后,由單個Controller/Action覆蓋全局配置。我們會演示1)和3)的場景。
我們準備使用獲取所有TodoLists的接口進行演示。
先看如何進行全局配置:
Program.cs
// 省略其他... builder.Services.AddControllers(options => { options.CacheProfiles.Add("60SecondDuration", new CacheProfile { Duration = 60 }); });
驗證1: 全局配置Caching
首先給我們要進行驗證的Action添加屬性:
TodoListController.cs
// 省略其他... [HttpGet] [ResponseCache(CacheProfileName = "60SecondDuration")] public async Task<ApiResponse<List<TodoListBriefDto>>> Get() { return ApiResponse<List<TodoListBriefDto>>.Success(await _mediator.Send(new GetTodosQuery())); }
啟動Api
項目,第一次執(zhí)行獲取TodoLists
的請求:
請求
響應(yīng)
響應(yīng)頭中多了一個cache-control
字段用于指明緩存的類型(public)以及過期時間為60s:
如果你是使用Postman
或者Insomia發(fā)送的請求,那么在過期前再次發(fā)起相同請求的返回頭中會再多出一個Age
字段,用于表明該資源當(dāng)前緩存了多少秒(Hoppscotch
我沒找到可以在哪里設(shè)置,所以下面的截圖是來自Insomia
,如果有哪位老哥知道的可以教一下):
同時如果觀察日志的話會發(fā)現(xiàn),第二次請求并沒有實際執(zhí)行SQL語句,這也證明了第二次請求的返回來自緩存:
如果間隔60s以上我們再去發(fā)送相同的請求,會發(fā)現(xiàn)日志中是這樣的:
可以看到緩存已經(jīng)失效了,此時需要重新向數(shù)據(jù)庫查詢返回數(shù)據(jù),并將這次請求結(jié)果緩存起來。
驗證2: 單個Action覆蓋全局配置
我們還是使用這個接口,但是修改一下屬性:
TodoListController.cs
[HttpGet] [ResponseCache(Duration = 120)] public async Task<ApiResponse<List<TodoListBriefDto>>> Get() { return ApiResponse<List<TodoListBriefDto>>.Success(await _mediator.Send(new GetTodosQuery())); }
重新啟動Api
項目,第一次執(zhí)行獲取TodoLists
的請求,請求和驗證1相同,我們來看響應(yīng)中的變化:
響應(yīng)
可以看到失效時間已經(jīng)變?yōu)?20s了,其他不再一一驗證。
在緩存中還有一個問題是,如果判斷緩存的數(shù)據(jù)內(nèi)容已經(jīng)變化,就需要去獲取最新的響應(yīng)而不是直接從緩存中取值。這是借助緩存校驗來完成的,而常使用的方式是通過Etag
實現(xiàn)。示意的過程如下:
如果首次請求資源,API會在響應(yīng)頭中添加Etag
和Last-Modified
字段:
當(dāng)客戶端再次請求資源時,由于緩存自身是不知道資源有沒有被修改,所以緩存會攜帶If-None-Match
字段(和客戶端收到的Etag
值相等)和If-Modified-Since
字段(和客戶端收到的Last-Modified
值相等)到API端,如果校驗發(fā)現(xiàn)資源沒有發(fā)生修改,那么API端無需重新獲取資源,直接返回304
字段(NotModifed)給緩存,緩存給客戶端返回值。如果校驗發(fā)現(xiàn)資源發(fā)生了修改,那么API將會返回新的結(jié)果。
我們給Api
項目添加Nuget包Marvin.Cache.Headers
,來實現(xiàn)此功能。
首先向Program
中添加服務(wù)以及引入中間件:
Program.cs
builder.Services.AddResponseCaching(); builder.Services.AddHttpCacheHeaders( expirationOptions => { expirationOptions.MaxAge = 180; expirationOptions.CacheLocation = CacheLocation.Private; }, validateOptions => { validateOptions.MustRevalidate = true; }); // 省略其他... app.UseResponseCaching(); app.UseHttpCacheHeaders();
同時我們需要移除之前添加的ResponseCache
屬性,因為新引入的庫已經(jīng)幫我們完成了,當(dāng)然我們也可以通過以下方式覆蓋全局配置:
[HttpCacheExpiration(CacheLocation = CacheLocation.Public, MaxAge = 60)] [HttpCacheValidation(MustRevalidate = false)]
覆蓋規(guī)則和框架內(nèi)置的規(guī)則是一致的,我不會繼續(xù)演示。
驗證3: 緩存校驗
請求仍然是獲取所有的TodoLists
:
響應(yīng)
我們暫時只關(guān)注響應(yīng)頭:
如果在緩存失效前我們添加了一個新的TodoList
,在請求頭中添加If-None-Match=53154EEFAE230D733827DBDE49B42AF9
再執(zhí)行獲取請求:
可以看到在失效時間到期之內(nèi),Etag
值已經(jīng)發(fā)生了變化,校驗表明資源已經(jīng)改變,需要重新獲取。
如果我們再次獲取相同的資源,會得到304
返回:
但是如果我們仔細觀察和思考就會發(fā)現(xiàn),框架在實現(xiàn)緩存校驗上存在兩個問題:
If-None-Match
頭字段是我們手動添加模擬的,這本應(yīng)該由緩存中間件來完成;
在響應(yīng)304
的情況下,實際上是沒有返回響應(yīng)體的,即緩存中未修改的資源沒有返回;
這兩個問題是由框架內(nèi)建的ResponseCaching
庫導(dǎo)致的,可以認為它沒有正確地實現(xiàn)緩存校驗機制。為此我們有一些替代方案可供參考:
Varnish
Apache Traffic Server
Squid
當(dāng)然使用專門的CDN
來做緩存也是可以的。
感謝大家的閱讀,以上就是“.NET 6開發(fā)中怎么實現(xiàn)緩存”的全部內(nèi)容了,學(xué)會的朋友趕緊操作起來吧。相信億速云小編一定會給大家?guī)砀鼉?yōu)質(zhì)的文章。謝謝大家對億速云網(wǎng)站的支持!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。