自從上次分享《Redis到底該如何利用？》已經有1年多了，這1年經歷了不少。從碼了我們網站的第一行開始到現在，我們的緩存模塊也不斷在升級，這之中確實略有心得，最近也有朋友探討緩存，覺得可以總結下分享下拙見，期待能有更深入的研究。 緩存是什麼？ 我時常在群里或者在社區里看到有人對緩存有諸多疑問，搞不清
自從上次分享《Redis到底該如何利用？》已經有1年多了，這1年經歷了不少。從碼了我們網站的第一行開始到現在，我們的緩存模塊也不斷在升級，這之中確實略有心得，最近也有朋友探討緩存，覺得可以總結下分享下拙見，期待能有更深入的研究。
緩存是什麼？
我時常在群里或者在社區里看到有人對緩存有諸多疑問，搞不清緩存的用途，分不清.NET Redis各驅動、中間件的區別和選擇。緩存其實並不是什麼看起來很深奧或者很難駕馭的東西，它一般是用來保存一些常用的數據到記憶體，以加快數據讀取，減少直接訪問DB流量以降低DB壓力。比較常用的場景比如：
- 靜態的維表類數據，比如地址庫，單位之類。
- 用戶Session
- 一些實時性高，訪問頻率高的計算數據，比如用戶訪問次數，文章閱讀量，用戶黑名單之類。
傳統的架構里，緩存純粹是DB數據的一份Copy，就像上面所說是為了程式能更快的讀取數據的。既然是Copy，其實就不必關心丟失，甚至微小的誤差。一定是最先保證DB，然後才是考慮緩存。另外現在分散式大行其道，集群比比皆是，緩存的應有就分成了多級，從單機記憶體到集中式緩存最後穿透的DB
但是現在很多大型互聯網架構里緩存是有不一樣的應用的，比如新浪微博，他們使用Redis並不是簡單的緩存，而是直接作為第一層的Storage，然後再非同步寫回DB。可以參考這篇。
最近遇到一次很有意思的討論，說到用戶黑名單功能的設計。有朋友DB依賴性超強，上來就是用戶表裡加欄位呀?讀取太慢？加索引啊之類之類。我覺得這個挺有意思的，以前我也是想當然的這樣想。為什麼？一開始做項目都是設計資料庫開始，建模就是ER圖，上來就是DB 三範式。以至於其實現在我都很難改變這樣的思維。導致學習OO，DDD之類建模思想始終繞不過DB First的思維。如果繞開DB，思考緩存去設計這樣的功能，可行性和性能都能提高不少。
.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最近也是很火，戳這裡。很多人搞不懂它是什麼樣的定位，它實際上是一個中間件，本身並不直接提供與緩存（Redis\mem）的對接API,當前的版本它是使用了StackExchange.Redis來作為驅動的，博客園裡已經有了很詳細的介紹(這裡)。它致力於屏蔽各種緩存服務的複雜度，提供簡單一致的API，讓開發者能夠用一套代碼，只要稍加配置就能使用MemroyCache/集中式緩存(redis/mem)。最強大的是它提供了多層緩存的方案（基於Redis Pub/Sub），只要簡單的配置就達到了多層之間的緩存同步。（內部的原理是，通過Redis Pub/Sub，每當緩存變動就通知sub們自動remove掉響應的緩存）。我們公司最近的一次更新也切換到了CacheManager.NET，不得不說它真的很好用。
合理設計緩存
1. 合理設計Key
緩存最重要的特點的是其Key-Value形式，即使Redis的多樣數據結構也是。Key-Value是保證其快速的根本原因,所以合理的Key，會讓搜索更方便。
這也會讓一份數據根據場景被設計成多分不同的Key-Value，例如:我之前的文章中提到的模糊匹配功能，就會把name設計進key，而如果是簡單的根據userid取用戶信息，則會把userid設計進key。從這裡也可以看出緩存並不介意保存很多一樣的數據。
2. 合理的使用緩存失效時間
上面提到緩存是可以丟失的，的確如果是記憶體緩存，它會隨著應用的進程的終止而釋放。除了這樣的釋放，緩存還可以被設置過期時間。為什麼要如此設計呢？試想機器記憶體一定不會比硬碟大呀，空間有效，珍貴的資源自然是要保存儘可能常用的數據（熱數據）。所以合理的設計失效時間會保持數據始終是最活躍的那一部分。當然失效時間也會引起，緩存雪崩等一系列問題，這裡有一篇深入的文章值得去看看（戳這裡）
未完待續。。。下一篇會繼續分享目前我所使用的緩存模塊，《.NET的緩存模塊設計》，涉及到ServiceStack.Redis的特性利用，CacheManager.NET的利用。
