如果說要對一個站點或者應用程序經常優化，可以說緩存的使用是最快也是效果最明顯的方式。一般而言，我們會把一些常用的，或者需要花費大量的資源或時間而產生的數據緩存起來，使得後續的使用更加快速。
如果真要細說緩存的好處，還真是不少，但是在實際的應用中，很多時候使用緩存的時候，總是那麼的不盡人意。換句話說，假設本來採用緩存，可以使得性能提升爲100（這裏的數字只是一個計量符號而已，只是爲了給大家一個“量”的體會），但是很多時候，提升的效果只有80,70，或者更少，甚至還會導致性能嚴重的下降，這個現象在使用分佈式緩存的時候尤爲突出。
在本篇文章中，我們將爲大家講述導致以上問題的9大症結，並且給出相對應的解決方案。文章以.NET爲例子進行代碼的演示，對於來及其他技術平臺的朋友也是有參考價值的，只要替換相對應的代碼就行了！
爲了使得後文的闡述更加的方便，也使得文章更爲的完整，我們首先來看看緩存的兩種形式：本地內存緩存，分佈式緩存。
首先對於本地內存緩存，就是把數據緩存在本機的內存中，如下圖1所示：
從上圖中可以很清楚的看出：
- 應用程序把數據緩存在本機的內存，需要的時候直接去本機內存進行獲取。
- 對於.NET的應用而言，在獲取緩存中的數據的時候，是通過對象的引用去內存中查找數據對象的，也就說，如果我們通過引用獲取了數據對象之後，我們直接修改這個對象，其實我們真正的是在修改處於內存中的那個緩存對象。
對於分佈式的緩存，此時因爲緩存的數據是放在緩存服務器中的，或者說，此時應用程序需要跨進程的去訪問分佈式緩存服務器，如圖2：
不管緩存服務器在哪裏，因爲涉及到了跨進程，甚至是跨域訪問緩存數據，那麼緩存數據在發送到緩存服務器之前就要先被序列化，當要用緩存數據的時候，應用程序服務器接收到了序列化的數據之後，會將之反序列化。序列化與反序列化的過程是非常消耗CPU的操作，很多問題就出現在這上面。
另外，如果我們把獲取到的數據，在應用程序中進行了修改，此時緩存服務器中的原先的數據是沒有修改的，除非我們再次將數據保存到緩存服務器。請注意：這一點和之前的本地內存緩存是不一樣的。
對於緩存中的每一份數據，爲了後文的講述方面，我們稱之爲“緩存項“。
普及完了這兩個概念之後，我們就進入今天的主題：使用緩存常見的9大誤區：
- 太過於依賴.NET默認的序列化機制
- 緩存大對象
- 使用緩存機制在線程間進行數據的共享
- 認爲調用緩存API之後，數據會被立刻緩存起來
- 緩存大量的數據集合，而讀取其中一部分
- 緩存大量具有圖結構的對象導致內存浪費
- 緩存應用程序的配置信息
- 使用很多不同的鍵指向相同的緩存項
- 沒有及時的更新或者刪除再緩存中已經過期或者失效的數據
下面，我們就每一點來具體的看看！
太過於依賴.NET默認的序列化機制
當我們在應用中使用跨進程的緩存機制，例如分佈式緩存memcached或者微軟的AppFabric，此時數據被緩存在應用程序之外的進程中。每次，當我們要把一些數據緩存起來的時候，緩存的API就會把數據首先序列化爲字節的形式，然後把這些字節發送給緩存服務器去保存。同理，當我們在應用中要再次使用緩存的數據的時候，緩存服務器就會將緩存的字節發送給應用程序，而緩存的客戶端類庫接受到這些字節之後就要進行反序列化的操作了，將之轉換爲我們需要的數據對象。
另外還有三點需要注意的就是：
- 這個序列化與反序列化的機制都是發生在應用程序服務器上的，而緩存服務器只是負責保存而已。
- .NET中的默認使用的序列化機制不是最優的，因爲它要使用反射機制，而反射機制是是非常耗CPU的，特別是當我們緩存了比較複雜的數據對象的時候。
基於這個問題，我們要自己選擇一個比較好的序列化方法來儘可能的減少對CPU的使用。常用的方法就是讓對象自己來實現ISerializable接口。
首先我們來看看默認的序列化機制是怎麼樣的。如圖3：
然後，我們自己來實現ISerializable接口，如下圖4所示：
我們自己實現的方式與.NET默認的序列化機制的最大區別在於：沒有使用反射。自己實現的這種方式速度可以是默認機制的上百倍。
可能有人認爲沒有什麼，不就是一個小小的序列化而已，有必要小題大做麼？
在開發一個高性能應用（例如，網站）而言，從架構，到代碼的編寫，以及後面的部署，每一個地方都需要優化。一個小問題，例如這個序列化的問題，初看起來不是問題，如果我們站點應用的訪問量是百萬，千萬，甚至更高級別的，而這些訪問需要去獲取一些公共的緩存的數據，這個之前所謂的小問題就不小了！
下面，我們來看第二個誤區。
緩存大對象
有時候，我們想要把一些大對象緩存起來，因爲產生一次大對象的代價很大，我們需要產生一次，儘可能的多次使用，從而提升響應。
提到大對象，這裏就很有必要對其進行一個比較深入的介紹了。在.NET中，所謂的大對象，就是指的其佔用的內存大於了85K的對象，下面通過一個比較將問題說清楚。
如果現在有一個Person類的集合，定義爲List<Person>，每個Person對象佔用1K的內存，如果這個Person集合中包含了100個Person對象實例，那麼這個集合是否是大對象呢？
回答是：不是！
因爲集合中只是包含的Person對象實例的引用而言，即，在.NET的託管堆上面，這個Person集合分配的內存大小也就是100個引用的大小而言。
然後，對於下面的這個對象，就是大對象了: byte[] data = new byte[87040]（85 * 1024 = 87040）。
說到了這裏，那就就談談，爲什麼說：產生一次大對象的代價很大。
因爲在.NET中，大對象是分配在大對象託管堆上面的（我們簡稱爲“大堆”，當然，還有一個對應的小堆），而這個大堆上面的對象的分配機制和小堆不一樣：大堆在分配的時候，總是去需找合適的內存空間，結果就是導致出現內存碎片，導致內存不足！我們用一個圖來描述一下，如圖5所示：
上圖非常明瞭，在圖5中：
-
- 垃圾回收機制不會在回收對象之後壓縮大堆（小堆是壓縮的）。
- 分配對象的時候，需要去遍歷大堆，去需找合適的空間，遍歷是要花成本的。
- 如果某些空間小於85K，那麼就不能分配了，只能白白浪費，也導致內存碎片。
講完了這些之後，我們言歸正傳，來看看大對象的緩存。
正如之前講過，將對象緩存和讀取的時候是要進行序列化與反序列化的，緩存的對象越大（例如，有1M等），整個過程中就消耗更多的CPU。
對於這樣的大對象，要看它使用的是否很頻繁，是否是公用的數據對象，還是每個用戶都要產生的。因爲我們一旦緩存了（特別在分佈式緩存中），就需要同時消耗緩存服務器的內存與應用程序服務器的CPU。如果使用的不頻繁，建議每次生成！如果是公用的數據，那麼建議多多的測試：將生產大對象的成本與緩存它的時候消耗的內存和CPU的成本進行比較，選擇成本小的！如果是每個用戶都要產生的，看看是否可以分解，如果實在不能分解，那麼緩存，但是及時的釋放！
使用緩存機制在線程間進行數據的共享
當數據放在緩存中的時候，我們程序的多個線程都可以訪問這個公共的區域。多個線程在訪問緩存數據的時候，會產生一些競爭，這也是多線程中常常發生的問題。
下面我們分別從本地內存緩存與分佈式緩存兩個方面介紹競爭的帶來的問題。
看下面的一段代碼：
對於本地內存緩存，對於上面的代碼，當這個三個線程運行起來之後，在線程1中，item的值很多時候可能爲1，線程2可能是2，線程3可能是3。當然，這不一定！只是大多數情況下的可能值！
如果是對於分佈式緩存，就不好說了！因爲數據的修改不是立刻發生在本機的內存中的，而是經過了一個跨進程的過程。
有一些緩存模塊已經實現了加鎖的方式來解決這個問題，例如AppFabric。大家在修改緩存數據的時候要特別注意這一點。
認爲調用緩存API之後，數據會被立刻緩存起來
有時候，當我們調用了緩存的API之後，我們就會認爲：數據已經被換成了，之後就可以直接讀取緩存中的數據。儘管情況很多時候如此，但是不是絕對的！很多的問題就是這樣產生的！
我們通過一個例子來講解。
例如，對於一個ASP.NET 應用而言，如果我們在一個按鈕的Click事件中調用了緩存API，然後在頁面呈現的時候，就去讀取緩存，代碼如下：
上面的代碼照道理來說是對的，但是會發生問題。按鈕點擊之後回傳頁面，然後呈現頁面的時候顯示數據，流程沒有問題。但是沒有考慮到這樣一個問題：如果服務器的內存緊張，而導致進行服務器內存的回收，那麼很有可能緩存的數據就沒有了！
這裏有朋友就要說了：內存回收這麼快？
這主要看我們的一些設置和處理。
一般而言，緩存機制都是會設置絕對過期時間與相對過期時間，二者的區別，大家應很清楚，我這裏不多說。對於上面的代碼而言，如果我們設置的是絕對過期時間，假設1分鐘，如果頁面處理的非常慢，時間超過了1分鐘，那麼等到呈現的時候，可能緩存中的數據已經沒有了！
有時候，即使我們在第一行代碼中緩存了數據，那麼也許在第三行代碼中，我們去緩存讀取數據的時候，就已經沒有了。這或許是因爲在服務器內存壓力很大的，緩存機制將最少訪問的數據直接清掉。或者服務器CPU很忙，網絡也不好，導致數據沒有被即使的序列化保存到緩存服務器中。
另外，對於ASP.NET而言，如果使用了本地內存緩存，那麼，還涉及到IIS的配置問題（對緩存內存的限制），我們有機會專門爲大家分享這方面的知識。
所以，每次在使用緩存數據的時候，要判斷是否存在，不然，會有很多的“找不到對象”的錯誤，產生一些我們認爲的“奇怪而又合理的現象”。
原Blog：http://www.infoq.com/cn/articles/misunderstanding-using-cache