使用asp.net Web Api構(gòu)建基于REST風(fēng)格的服務(wù)實(shí)戰(zhàn)系列教程【十】——使用CacheCow和ETag緩存資源

系列導(dǎo)航地址http://m.survivalescaperooms.com/fzrain/p/3490137.html

前言

本文將使用一個(gè)開源框架CacheCow來實(shí)現(xiàn)針對Http請求資源緩存，本文主要介紹服務(wù)器端的緩存。

使用緩存技術(shù)可以很好的提高Web Api的性能，減小服務(wù)器的開銷。我們把這種緩存形式稱之為：條件化請求（Conditional Requests）。具體表現(xiàn)為：客戶端向服務(wù)器請求時(shí)會(huì)附加一個(gè)請求頭ETag，然后服務(wù)器會(huì)根據(jù)這個(gè)信息來決定是否需要把更新過的資源響應(yīng)給客戶端，如果需要，則響應(yīng)200狀態(tài)嗎以及資源內(nèi)容，否則響應(yīng)304狀態(tài)碼（Not modified）以及一個(gè)空的響應(yīng)正文。

什么是ETag?

寫了好多，那么什么是ETag呢？ETag是服務(wù)器為特定資源生成的一個(gè)唯一標(biāo)識(shí)（string類型）。你也可以理解為用來檢查服務(wù)器資源是否變化。

ETag分2種類型：強(qiáng)類型和弱類型。對于弱類型的ETag包含一個(gè)前綴W（例如：W/53fsfsd322），而強(qiáng)類型的ETag不包含任何前綴（例如：53fsfsd322）。通常來說，弱類型ETag代表緩存短時(shí)間資源（內(nèi)存緩存），而強(qiáng)類型的ETag緩存是靠持久化的方式來實(shí)現(xiàn)的。

ETag工作原理

先上一張圖：

由上圖可知：在一開始，客戶端發(fā)起一個(gè)Http Get請求，請求的是id為4的course資源，由于這個(gè)資源是第一次被訪問，因此服務(wù)器在把資源返回的同時(shí)附加了一個(gè)響應(yīng)頭（ETag）。

現(xiàn)在，客戶端發(fā)送Http Get請求想要再次請求相同的資源（Course id: 4），考慮到客戶端使用緩存，因此Get請求初始化的時(shí)候增加一個(gè)Header（If-None-Match），內(nèi)容就是資源的ETag值。當(dāng)服務(wù)器接受到請求的時(shí)候，就會(huì)讀取ETag的值并與服務(wù)器內(nèi)的ETag值做比較，如果完全相同，服務(wù)器就會(huì)返回304狀態(tài)碼（Not modified）并且正文不含任何內(nèi)容。這樣客戶端就知道資源是最新的。

對于Http Get和Delete請求，我們可以使用（If-None-Match）頭，但對于更新時(shí)我們要使用（If-Match）來匹配Put/Patch請求。請求到達(dá)的時(shí)候，服務(wù)器會(huì)校驗(yàn)ETag值，如果不一樣，服務(wù)器就會(huì)響應(yīng)一個(gè)412狀態(tài)碼（PRecondition Failed），因此客戶端就知道自己的版本不是最新的，在客戶端沒有獲取最新資源之前是不允許更新的。

在Web Api中配置CacheCow

經(jīng)過了之前的一段簡單介紹，我們來實(shí)現(xiàn)所謂的“條件化請求”。

我們需要使用NuGet來安裝CacheCow，打開NuGet控制臺(tái)，輸入“Install-Package CacheCow.Server -Version 0.4.12”。會(huì)安裝2個(gè)dll：CacheCow.Server和CacheCow.Common。

配置CacheCow也是非常簡單的，我們所需要做的是創(chuàng)建一個(gè)Cache Handler并把它注入到web api的請求管道中。這個(gè)handler就是在請求到達(dá)和離開web api的時(shí)候檢查ETag和生成ETag的。

為了實(shí)現(xiàn)這一點(diǎn)，在“WebApiConfig.cs”里做如下配置：

//Configure HTTP Caching using Entity Tags (ETags)var cacheCowCacheHandler = new CacheCow.Server.CachingHandler();config.MessageHandlers.Add(cacheCowCacheHandler);

到目前為止，我們的web api已經(jīng)具有使用本機(jī)內(nèi)存實(shí)現(xiàn)緩存的功能了，這也是CacheCow默認(rèn)的配置，在單機(jī)狀態(tài)（只有一臺(tái)服務(wù)器）的時(shí)候可謂是比較完美了。然而，當(dāng)應(yīng)用程序走向分布式的時(shí)候就出現(xiàn)為題了——由于不同的web服務(wù)器需要共享緩存狀態(tài)，因此我們需要把緩存狀態(tài)持久化到一個(gè)單獨(dú)的地方（SQL Server, MongoDB, MemCache）。但是在實(shí)現(xiàn)持久化之前我們先測試一下內(nèi)存緩存。

打開我們的測試客戶端PostMan（Chrome插件），發(fā)送Get請求到：http://localhost:{your_port}/api/courses/4

結(jié)果：

請求注釋：

1.響應(yīng)Http狀態(tài)碼是200，意昧著服務(wù)器把資源一起響應(yīng)過來了。

2.這次響應(yīng)增加了2條頭信息：ETag和Last-Modified，目前我們只需關(guān)心ETag的值，因?yàn)橄麓握埱髸?huì)用到。

3.ETag的類型是弱類型的（帶有W前綴），說明這個(gè)緩存存在于服務(wù)器的內(nèi)存中，如果重啟IIS或切斷服務(wù)進(jìn)程的話，緩存就會(huì)失效。

對于接受到ETag值的客戶端，在下次請求相同資源的時(shí)候就需要附加一個(gè)“If-None-Match”的請求頭，服務(wù)器就會(huì)比較客戶端與自己內(nèi)存中的ETag值，如果相同，返回304（Not modified），不相同則返回200加上資源內(nèi)容。

測試：我們再次請求這個(gè)資源

結(jié)果：

對于這次請求來說：

1.http狀態(tài)碼是304，意味著客戶端的資源是最新的，因此響應(yīng)body是空的

2.客戶端得到相同的ETag值

在SQL Server端實(shí)現(xiàn)緩存

在SQL Server中做緩存同樣很簡單，首先我們要確定在哪個(gè)持久化介質(zhì)中實(shí)現(xiàn)緩存，我們用的是SQL Server,因此打開NuGet控制臺(tái)，輸入如下命令：Install-Package CacheCow.Server.EntityTagStore.SqlServer -Version 0.4.11。

然后在“WebApiConfig”做如下配置：

//Configure HTTP Caching using Entity Tags (ETags)var connString = System.Configuration.ConfigurationManager.ConnectionStrings["eLearningConnection"].ConnectionString;var eTagStore = new CacheCow.Server.EntityTagStore.SqlServer.SqlServerEntityTagStore(connString);var cacheCowCacheHandler = new CacheCow.Server.CachingHandler(eTagStore);cacheCowCacheHandler.AddLastModifiedHeader = false;config.MessageHandlers.Add(cacheCowCacheHandler);

上面的實(shí)現(xiàn)很明顯，CacheCow需要把緩存信息存到數(shù)據(jù)庫中，因此我們需要制定我們api所用的數(shù)據(jù)庫。然后把eTagStore實(shí)例賦給Cache handler。

如果你現(xiàn)在直接請求api的話，等待你的不是資源而是一個(gè)500錯(cuò)誤碼。這是因?yàn)橹拔覀兘榻B到CacheCow需要把緩存信息存入數(shù)據(jù)庫，那么數(shù)據(jù)庫中就應(yīng)該有一張對應(yīng)的表以及操作這張表的存儲(chǔ)過程，因此我們需要執(zhí)行一個(gè)sql腳本。這個(gè)腳本通常在“{projectpath}/packages/CacheCow.Server.EntityTagStore.SqlServer.0.4.11/script”

執(zhí)行完這個(gè)腳本后，你會(huì)發(fā)現(xiàn)數(shù)據(jù)庫多了一張表以及5個(gè)存儲(chǔ)過程：

ok，可以測試了，還是剛剛的例子：

正如上圖所示，ETag的值不再是弱類型的了，因此我們存到SQL Server中了，打開SQL Server中的CacheState表，你會(huì)發(fā)現(xiàn)：

現(xiàn)在，只要沒有客戶端來更新這個(gè)資源，之前訪問過這個(gè)資源的客戶端統(tǒng)統(tǒng)會(huì)得到304狀態(tài)碼以及空的body（前提是客戶端的請求中包含ETag值，呵呵）。

現(xiàn)在我們實(shí)現(xiàn)一下更新，客戶端要更新資源就需要包含一個(gè)“If-Match”的請求頭，如下圖所示：

結(jié)果：

ETag已經(jīng)改變：

我們使用老的ETag再次請求服務(wù)器：

所以結(jié)果：

這個(gè)響應(yīng)告訴客戶端：”你手里的資源不是最新的，先拿到最新的資源我才讓你修改”。

總結(jié)

拖了好久的最后一篇終于和大家見面了，主要都是一些理論，代碼也就5行，不過感覺ETag還真的挺強(qiáng)大的。

本次系列到這里也要告一段落了，不過之后還打算介紹一些有其他內(nèi)容（包括Web Api 2的新特性IHttpActionResult，CORS的支持以及OData的支持等），敬請期待。。。

源碼地址：https://github.com/fzrain/WebApi.eLearning