概述
我們所說的快取分為程式內部快取（系統內部快取）和 快取服務（如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、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、謹防快取擊穿、雪崩的產生，這個我們有慘痛的教訓，後續來一篇專門分析下。