作者：翁智華
出處：https://www.cnblogs.com/wzh2010/
概述
我們所說的快取分為行程內部快取（系統內部快取）和 快取服務（如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、謹防快取擊穿、雪崩的產生，這個我們有慘痛的教訓，后續來一篇專門分析下，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/292294.html
標籤：其他
上一篇：行程快取和快取服務，如何抉擇？
下一篇：# Day08-Java基礎