自從上次分享《Redis到底該如何利用？》已經有1年多了，這1年經歷了不少。從碼了我們網站的第一行開始到現在，我們的緩存模塊也不斷在升級，這之中確實略有心得，最近也有朋友探討緩存，覺得可以總結並分享一下拙見，期待能有更深入的研究。 緩存是什麼？ 我時常在群里或者在社區里看到有人對緩存有諸多疑問，搞不 ...
自從上次分享《Redis到底該如何利用？》已經有1年多了，這1年經歷了不少。從碼了我們網站的第一行開始到現在，我們的緩存模塊也不斷在升級，這之中確實略有心得，最近也有朋友探討緩存，覺得可以總結並分享一下拙見，期待能有更深入的研究。
緩存是什麼？
我時常在群里或者在社區里看到有人對緩存有諸多疑問，搞不清緩存的用途，分不清.NET Redis各驅動、中間件的區別和選擇。緩存其實並不是什麼看起來很深奧或者很難駕馭的東西，它一般是用來保存一些常用的數據到記憶體，以加快數據讀取，減少直接訪問DB流量以降低DB壓力。
比較常用的場景比如：
靜態的維表類數據，比如地址庫，單位之類。
用戶Session
一些實時性高，訪問頻率高的計算數據，比如用戶訪問次數，文章閱讀量，用戶黑名單之類。
傳統的架構里，緩存純粹是DB數據的一份Copy，就像上面所說是為了程式能更快的讀取數據的。既然是Copy，其實就不必關心丟失，甚至微小的誤差。一定是最先保證DB，然後才是考慮緩存。另外現在分散式大行其道，集群比比皆是，緩存的應用就分成了多級，從單機記憶體到集中式緩存到最後穿透到DB。
但是現在很多大型互聯網架構里緩存是有不一樣的應用的，比如新浪微博，他們使用Redis並不是簡單的緩存，而是直接作為第一層的Storage，然後再非同步寫回DB。可以參考《新浪微博關係服務與Redis的故事》。
最近遇到一次很有意思的討論，說到用戶黑名單功能的設計。有朋友DB依賴性超強，上來就是用戶表裡加欄位呀?讀取太慢？加索引啊之類之類。我覺得這個挺有意思的，以前我也是想當然的這樣想。為什麼？一開始做項目都是設計資料庫開始，建模就是ER圖，上來就是DB 三範式。以至於其實現在我都很難改變這樣的思維。導致學習OO，DDD之類建模時，思想始終繞不過DB First的思維。如果繞開DB，思考緩存去設計這樣的功能，可行性和性能都能提高不少。
（緩存穿透：一般的緩存系統，都是按照key去緩存查詢，如果不存在對應的value，就應該去後端系統查找（比如DB）。如果key對應的value是一定不存在的（資料庫裡面沒有此值，也無法更新緩存，但DB也要被執行），並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做緩存穿透。
解決方案：對查詢結果為空的情況也進行緩存，緩存時間設置短一點，或者該key對應的數據insert了之後清理緩存。）
.NET下的緩存應用
針對單機應用，記憶體緩存（System.Runtime.Caching）就足夠，集群環境應該上集中式緩存，比較常用的是memcached和Redis，這兩者的區別倒是可以好好說道說道。
memcached更加的像記憶體緩存，功能單一，只能做普通的緩存操作（Put/Get/Remove...）
Redis功能更加豐富一些，也支持更多的數據結構，更多的計算命令，因此例如Session等緩存模塊更加的適合memcached，而帶實時計算性質的更加適合Redis。不過同時用上兩種服務，也只有大公司能幹了，一般人像我，還是比較喜歡Redis，畢竟功能豐富。
關於Redis的驅動，我也經常看到SeviceStack.Redis/StackExchange.Redis搞得大家不知道取捨。
兩個我都用，因為ServiceStack本來是開源免費後來為了支撐發展吧，人家順便就在V4之後開始加入限制，開始收錢了。不過V3依然免費，使用的時候需要註意所有的依賴都要用V3以下哦。V3版本很遺憾，很多功能並不能很好的支持，比如Pub/Sub.
StackExchange.Redis源自鼎鼎大名的StackOverFlow，他們有網站的收入，自然熱衷開源免費。不過質量還是非常靠譜的，新功能支持的很好。
以上在GitHub上一搜便有。
另外一個開源項目CacheManager.NET最近也是很火，可參考GitHub相關開源代碼。很多人搞不懂它是什麼樣的定位，它實際上是一個中間件，本身並不直接提供與緩存（Redis\mem）的對接API，當前的版本它是使用了StackExchange.Redis來作為驅動的，博客園裡已經有了很詳細的介紹，如《.Net緩存管理框架CacheManager》。它致力於屏蔽各種緩存服務的複雜度，提供簡單一致的API，讓開發者能夠用一套代碼，只要稍加配置就能使用MemroyCache/集中式緩存(redis/mem)。最強大的是它提供了多層緩存的方案（基於Redis Pub/Sub），只要簡單的配置就達到了多層之間的緩存同步。（內部的原理是，通過Redis Pub/Sub，每當緩存變動就通知sub們自動remove掉響應的緩存）。我們公司最近的一次更新也切換到了CacheManager.NET，不得不說它真的很好用。
（“集中式緩存"與"分散式緩存"的區別其實就在於“集中”與"非集中"的概念，其對象可能是伺服器、記憶體條、硬碟等。
比如：----1.伺服器版本：
----.----緩存集中在一臺伺服器上，為集中式緩存。
----.----緩存分散在不同的伺服器上，為分散式緩存。
----2.記憶體條版本：
----.----緩存集中在一臺伺服器的一條記憶體條上，為集中式緩存。
----.----緩存分散在一臺伺服器的不同記憶體條上，為分散式緩存。
----3.硬碟版本：
----.----緩存集中在一臺伺服器的一個硬碟上，為集中式緩存。
----.----緩存分散在一臺伺服器的不同硬碟上，為分散式緩存。）
合理設計緩存
1. 合理設計Key
緩存最重要的特點的是其Key-Value形式，即使Redis的多樣數據結構也是。Key-Value是保證其快速的根本原因,所以合理的Key，會讓搜索更方便。
這也會讓一份數據根據場景被設計成多份不同的Key-Value，例如:我之前的文章中提到的模糊匹配功能，就會把name設計進key，而如果是簡單的根據userid取用戶信息，則會把userid設計進key。從這裡也可以看出緩存並不介意保存很多一樣的數據。
2. 合理的使用緩存失效時間
上面提到緩存是可以丟失的，的確如果是記憶體緩存，它會隨著應用的進程的終止而釋放。除了這樣的釋放，緩存還可以被設置過期時間。為什麼要如此設計呢？試想機器記憶體一定不會比硬碟大呀，空間有效，珍貴的資源自然是要保存儘可能常用的數據（熱數據）。
所以合理的設計失效時間會保持數據始終是最活躍的那一部分。當然失效時間也會引起，緩存雪崩等一系列問題，這裡有一篇深入的文章值得去看看《Web開發基本準則-55實錄-緩存策略》
（緩存雪崩：當緩存伺服器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會給後端系統(比如DB)帶來很大壓力。
解決方案：
1：在緩存失效後，通過加鎖或者隊列來控制讀資料庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。 2：不同的key，設置不同的過期時間，讓緩存失效的時間點儘量均勻。 3：做二級緩存，A1為原始緩存，A2為拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置為短期，A2設置為長期（此點為補充）） 原文地址：http://www.cnblogs.com/capqueen/p/CacheAgain.html
