相關文章：使用緩存的9大誤區（上）
本篇文章在上篇的基礎上繼續讨論了使用緩存的幾個誤區，包括：緩存大量的資料集合，而讀取其中一部分；緩存大量具有圖結構的對象導緻記憶體浪費；緩存應用程式的配置資訊；使用很多不同的鍵指向相同的緩存項；沒有及時的更新或者删除再緩存中已經過期或者失效的資料。
5.緩存大量的資料集合，而讀取其中一部分
在很多時候，我們往往會緩存一個對象的集合，但是，我們在讀取的時候，隻是每次讀取其中一部分。 我們舉個例子來說明這個問題（例子可能不是很恰當，但是足以說明問題）。
在購物站點中，常見的操作就是查詢一些産品的資訊，這個時候，如果使用者輸入了“25寸電視機”，然後查找相關的産品。這個時候，在背景，我們可以查詢資料庫，找到幾百條這樣的資料，然後，我們将這幾百條資料作為一個緩存項緩存起來，代碼的代碼如下：
同時，我們對找出的産品進行分頁的顯示，每次展示10條。其實在每次分頁的時候，我們都是根據緩存的鍵去擷取資料，然後選擇下一個10條資料，然後顯示。
如果是使用本地記憶體緩存，那麼這可能不是什麼問題，如果是采用分布式緩存，問題就來了。下圖可以清楚的說明這個過程，如圖所示：
相信大家看完這個圖，然後結合之前的講述應該很清楚了問題所在了：每次都按照緩存鍵擷取全部資料，然後在應用伺服器那裡反序列化全部資料，但是隻是取其中10條。
這裡可以将資料集合再次拆分，分為例如25-0-10-products，25-11-20-products等的緩存項，如下圖所示：
當然，查詢和緩存的方式有很多，拆分的方式也有很多，這裡這是給出一些常見的問題！
6.緩存大量具有圖結構的對象導緻記憶體浪費
為了更好的說明這個問題，我們首先看到下面的一個類結構圖，如圖：
如果我們要把一些Customer資料緩存起來，這裡就可以可能出現兩個問題：
由于使用.NET的預設序列化機制，或者沒有适當的加入相應Attribute（屬性），使得緩存了一些原本不需要緩存的資料。
将Customer緩存的時候，同時，為了更快的擷取Customer的Order資訊，将Order資訊緩存在了另外一個緩存項中，導緻同一份資料被緩存兩次。
下面，我們就分别來看看這兩個問題。
首先看到第一個。如果我們使用分布式緩存來緩存一些Customer的資訊的時候，如果我們沒有自己重新Customer的序列化機制，而是采用的預設的，那麼序列化機制在序列化Customer的時候，會将Customer所引用的對象也序列化，然後在序列化被序列化對象中的其他引用對象，最後的結果就是：Customer被序列化，Customer的Order資訊被序列化，Order引用的OrderItem被序列化，最後OrderItem引用的Product也會序列化。
整個對象圖全部被序列化了，如果這種情況是我們想要的，那麼沒有問題；如果不是的，那麼，我們就浪費了很多的資源了，解決的方法有兩個：第一，自己實作序列化，自己完全控制哪些對象需要序列化，我們前面已經講過了；第二，如果使用預設的序列化機制，那麼在不要需要序列化的對象上面加上[NonSerialized]标記。
下面，我們看到第二個問題。這個問題主要是由于第一個問題引起的：原本在緩存Customer的時候，已經将Customer的其他資訊，例如Order，Product已經緩存了。但是很多的技術人員不清楚這一點，然後又把Customer的Order資訊去緩存在其他的緩存項，使用的使用就根據Customer的辨別，例如ID去緩存中擷取Order資訊，如下代碼所示：
解決這個問題的方法也比較明顯，參看第一個問題的解決方案就可以了！
7.緩存應用程式的配置資訊
因為緩存是有一套資料失效檢測周期的（之前說過，要麼是固定時間失效，要麼是相對時間失效），是以，很多的技術人員喜歡把一些動态變化的資訊儲存在緩存中，以充分利用緩存機制的這種特性，其中，緩存程式的配置資訊就是其中一個例子。
因為在應用的中的一些配置，可能會發生變化，最簡單的就是資料庫連接配接字元串了，如下代碼：
當這樣設定之後，每隔一段時間緩存失效之後，就去重新讀取配置檔案，這時候，可能此時的配置就和之前不一樣了，并且其他的地方都可以讀取緩存進而進行更新，特别是在多台伺服器上面部署同一個站點的時候，有時候，我們沒有及時的去修改每個伺服器上面的站點的配置檔案裡面的資訊，這個時候如何使用分布式緩存緩存配置資訊，隻要更新一個站點的配置檔案，其他站點就全部修改了，技術人員皆大歡喜。OK，這确實看起來是個不錯的方法（在必要的時候可以采用一下），但是，不是所有的配置資訊都要保持一樣的，而且還要考慮怎樣一個情況：如果緩存伺服器出了問題，當機了，那麼我們所有使用這個配置資訊的站點可能都會出問題。
建議對于這些配置檔案的資訊，采用監控的機制，例如檔案監控，每次檔案發生變化，就重新加載配置資訊。
8.使用很多不同的鍵指向相同的緩存項
我們有時候會遇到這樣的一個情況：我們把一個對象緩存起來，用一個鍵作為緩存鍵來擷取這個資料，之後，我們又通過一個索引作為緩存鍵來擷取這個資料，如下代碼所示：
我們之是以這樣寫，主要因為我們會以多種方式來從緩存中讀取資料，例如在進行循環周遊的時候，需要通過索引來擷取資料，例如index++等，而有些情況，我們可能需要通過其他的方式，例如，産品名來擷取産品的資訊。
如果遇到這樣的情況，那麼就建議将這些多個鍵組合起來，形成如下的形式：
另外一個常見的問題就是：相同的資料被緩存在不同的緩存項中，例如，如果使用者查詢尺寸為36寸的彩電，那麼可能有可能一個編号為100的電視産品就在結果中，此時，我們将結果緩存。另外，使用者在查找一個生産廠家為TCL的電視，如果編号為100的電視産品又出現在結果中，我們把結果又緩存在另外一個緩存項中。這個時候，很顯然，出現了記憶體的浪費。
對于這樣的情況，之前筆者采用的方法就是，在緩存中建立了一個索引清單，如圖所示：
當然，這其中有很多的細節和問題需要解決，這裡就不一一述說，要看各自的應用和情況而定！ 也非常歡迎大家提供更好的方法。
9.沒有及時的更新或者删除再緩存中已經過期或者失效的資料
這種情況應該是使用緩存最常見的問題，例如，如果我們現在擷取了一個Customer的所有沒有處理的訂單的資訊，然後緩存起來，類似的代碼如下：
之後，使用者的一個訂單被處理了，但是緩存還沒有更新，那麼這個時候，緩存中的資料就已經有問題！當然，我這裡隻是列舉的最簡單的場景，大家可以聯想自己應用中的其他産品，很有可能會出現緩存中的資料和實際資料庫中的不一樣。
現在很多的時候，我們已經容忍了這種短時間的不一緻的情況。其實對于這種情況，沒有非常完美的解決方案，如果要做，倒是可以實作，例如每次修改或者删除一個資料，就去周遊緩存中的所有資料，然後進行操作，但是這樣往往得不償失。另外一個折中的方法就是，判斷資料的變化周期，然後盡可能的将緩存的時間變短一點。