概述
我們所說的緩存分為進程內部緩存（系統內部緩存）和 緩存服務（如redis/memcache）。計算機服務從原來的單體結構，到多實例，到現在流行的微服務，緩存服務變得原來越流行了。
進程緩存
先說說進程緩存，它將數據存儲在站點、服務的進程內。在Web的發展歷史上，這樣的方式備受歡迎。比如早期常用的.Net的 System.Web.Caching.
這種實現載體很簡單，比如一個帶鎖的HasTable，或者一個List對象。 使用簡單便捷，能存儲數據、html頁面片段、文件，甚至任何對象。
在單體結構的Web模式下，進程內緩存被開發到極致，大概流程如下圖：
與原先沒有緩存相比，進程內緩存的好處是，數據讀取不再直接訪問數據庫，先判斷緩存中是否存在，如果存在，則直接讀取，不存在則再去數據庫中取，同時寫入緩存。
這樣避免了每次的請求都走數據庫，減少網絡開銷和數據請求次數，提高了數據獲取效率，基本等同在內存中執行。
緩存的目的是為了
冷熱數據的隔離，對於頻繁被修改的數據，緩存的意義不是很大，比如微信用戶的實時步數。比較有價值的是那些不被頻繁修改且數據量較大的內容，比如系統字典、配置數據。
判斷是否需要創建緩存需要一定的依據，以下是我的團隊的策略，不一定適用，可以參考：
緩存的必要性：數據的變更是否過於頻繁，過於頻繁則可能導致緩存不斷重建，反而降低效率。 評估方式：緩存的過期時間內沒被主動更新的量值應該超過60%。
假設緩存時間：3600s
假設同一種類型緩存數據基數：6000個
6000 * 60% = 3600 的數據在一個小時內事務未更新，這樣的緩存價值更大。
進程緩存的問題
在互聯網大潮下，隨着用戶量的激增，原來單體結構逐漸的向Web服務集群發展，在多實例目標下，進程緩存的弊端越來越明顯。
比如緩存無法統一的問題。
如果站點和服務中的多個節點訪問統一的緩存服務（比如redis 或者 memerche），數據統一存儲，數據的一致性就比較容易保障。
但如果是進程緩存，數據存儲在站點和服務的多個節點內，每個節點一個緩存，存儲多份，一致性就比較難保障。
如上圖，但是有個問題，Cache1、Cache1、Cache3一致性難以保障，如果想保持緩存的一致性時，該怎么辦呢？
一般有以下幾種方法：
1、單一服務節點通知其他服務節點，如果我們只是Web Service1 在執行業務操作的時候修改數據庫，更新緩存，同時通知其他Web Service
服務，其他Web Service 接收到信息的時候，進行緩存更新。
2、 啟動MQ通知其他節點：如下圖，可以通過MQ通知其他節點。寫請求發生在server1，在修改完自己緩存數據與數據庫中的數據之后，給MQ生產數據變化通知，
server2和server1訂閱MQ消息，當消費到MQ信息的時候，也修改緩存數據。
3、有一種簡單的方式，也可以解耦與Web Server的關系，就是直接放棄了“實時一致性”，啟動一個獨立的進程服務，定時從后端拉取最新的數據，更新內存緩存。
上述的幾種方法為了保持數據的一致性，增加了一定的開銷，一方面緩存數據同步過程中會有出錯的風險；
另一方面實際上違背了緩存的原則：冷熱數據隔絕，有效的利用冷數據，減輕數據庫壓力，提升效率。如果緩存被頻繁修改或者同步，那緩存的價值就不大了。
補充：1、2 兩種方式，實例越多，緩存冗余越多，各緩存節點數據同步的原子性越難保證，一致性也就越難保證。
第3種方式：采用定時拉取本身已經放棄了數據的實時一致性。
所以我們在以下這幾種情況下拋棄進程緩存，選用緩存服務：
1、Web集群下，包含多個實例，並且不允許業務數據的不一致性（我相信大部分業務不允許）
2、進程內緩存數據量較大，緩存內存空間不足，影響Web性能，可以考慮走緩存服務（緩存服務如redis，一般獨立服務甚至集群配置，支持超大量級）。
3、評估value大小、緩存內存空間、峰值QPS、過期時間、緩存命中率、讀寫更新策略、key值分布路由策略、過期策略以及數據一致性方案，根據實際需要判斷是否走緩存服務。
緩存服務
在互聯網分層架構中，最常用的kv結構的緩存是redis。他有如下特點：
1、它支持復雜數據結構
value是字符串、哈希，列表，集合，有序集合這類復雜的數據結構。支持各種場景，如客戶訂單信息列表，用戶消息，帖子評論等。
2、支持持久化
首先，redis的所有數據都是保存在內存中，然后不定期的通過異步方式保存到磁盤上(這稱為“半持久化模式”)；
也可以把每一次數據變化都寫入到一個append only file(aof)里面(這稱為“全持久化模式”，效率會低一點)。
但是我們盡量不要把redis當作數據庫用，如果真的需要持久化數據，建議可以走MySQL：
2.1、redis的定期快照不能保證數據不丟失
2.2、redis的AOF會降低效率，並且不能支持太大的數據量
3、具備高可用特性
redis天然支持集群功能，可以實現主動復制，讀寫分離。 官方也提供了sentinel集群管理工具，能夠實現主從服務監控，故障自動轉移。
4、存儲的內容比較大
String類型：一個String類型的value最大可以存儲512M，List、Set、Hash類型：list的元素個數最多為2^32-1個，也就是4294967295個。
5、 支持事務
操作都是原子性，對數據的更改要么全部執行，要么全部不執行。避免業務數據的不一致性。
緩存使用注意
1、Web服務 單體模式轉為多實例之后，我們將進程緩存升級為緩存服務（redis），清清理了所有的緩存使用，都改成了對接redis。但是有一些地方漏掉，因為我們有3個實例，所以漏掉的那幾個地方，一旦修改某個數據之后，一會兒是新值，一會兒舊值，很神奇。
2、謹防緩存擊穿、雪崩的產生，這個我們有慘痛的教訓，后續來一篇專門分析下。