系統(tǒng)架構(gòu)設(shè)計：進(jìn)程緩存和緩存服務(wù)，如何抉擇？
[導(dǎo)讀]作者：翁智華來源：https://www.cnblogs.com/wzh2010/p/13874206.html概述我們所說的緩存分為進(jìn)程內(nèi)部緩存（系統(tǒng)內(nèi)部緩存）和緩存服務(wù)（如redis/memcache）。計算機(jī)服務(wù)從原來的單體結(jié)構(gòu)，到多實例，到現(xiàn)在流行的微服務(wù)，緩存服務(wù)變得原...
作者：翁智華來源：https://www.cnblogs.com/wzh2010/p/13874206.html
概述
我們所說的緩存分為進(jìn)程內(nèi)部緩存（系統(tǒng)內(nèi)部緩存）和 緩存服務(wù)（如redis/memcache）。計算機(jī)服務(wù)從原來的單體結(jié)構(gòu)，到多實例，到現(xiàn)在流行的微服務(wù)，緩存服務(wù)變得原來越流行了。??
?
與原先沒有緩存相比，進(jìn)程內(nèi)緩存的好處是，數(shù)據(jù)讀取不再直接訪問數(shù)據(jù)庫，先判斷緩存中是否存在，如果存在，則直接讀取，不存在則再去數(shù)據(jù)庫中取，同時寫入緩存。這樣避免了每次的請求都走數(shù)據(jù)庫，減少網(wǎng)絡(luò)開銷和數(shù)據(jù)請求次數(shù)，提高了數(shù)據(jù)獲取效率，基本等同在內(nèi)存中執(zhí)行。緩存的目的是為了冷熱數(shù)據(jù)的隔離，對于頻繁被修改的數(shù)據(jù)，緩存的意義不是很大，比如微信用戶的實時步數(shù)。比較有價值的是那些不被頻繁修改且數(shù)據(jù)量較大的內(nèi)容，比如系統(tǒng)字典、配置數(shù)據(jù)。判斷是否需要創(chuàng)建緩存需要一定的依據(jù)，以下是我的團(tuán)隊的策略，不一定適用，可以參考：緩存的必要性：數(shù)據(jù)的變更是否過于頻繁，過于頻繁則可能導(dǎo)致緩存不斷重建，反而降低效率。評估方式：緩存的過期時間內(nèi)沒被主動更新的量值應(yīng)該超過60%。假設(shè)緩存時間：3600s假設(shè)同一種類型緩存數(shù)據(jù)基數(shù)：6000個?6000 * 60% = 3600 的數(shù)據(jù)在一個小時內(nèi)事務(wù)未更新，這樣的緩存價值更大。??如上圖，但是有個問題，Cache1、Cache1、Cache3一致性難以保障，如果想保持緩存的一致性時，該怎么辦呢？一般有以下幾種方法：1、單一服務(wù)節(jié)點通知其他服務(wù)節(jié)點，如果我們只是Web Service1 在執(zhí)行業(yè)務(wù)操作的時候修改數(shù)據(jù)庫，更新緩存，同時通知其他Web Service服務(wù)，其他Web Service 接收到信息的時候，進(jìn)行緩存更新。??2、 啟動MQ通知其他節(jié)點：如下圖，可以通過MQ通知其他節(jié)點。寫請求發(fā)生在server1，在修改完自己緩存數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)之后，給MQ生產(chǎn)數(shù)據(jù)變化通知，server2和server1訂閱MQ消息，當(dāng)消費(fèi)到MQ信息的時候，也修改緩存數(shù)據(jù)。?3、有一種簡單的方式，也可以解耦與Web Server的關(guān)系，就是直接放棄了“實時一致性”，啟動一個獨立的進(jìn)程服務(wù)，定時從后端拉取最新的數(shù)據(jù)，更新內(nèi)存緩存。?上述的幾種方法為了保持?jǐn)?shù)據(jù)的一致性，增加了一定的開銷，一方面緩存數(shù)據(jù)同步過程中會有出錯的風(fēng)險；另一方面實際上違背了緩存的原則：冷熱數(shù)據(jù)隔絕，有效的利用冷數(shù)據(jù)，減輕數(shù)據(jù)庫壓力，提升效率。如果緩存被頻繁修改或者同步，那緩存的價值就不大了。??補(bǔ)充：1、2 兩種方式，實例越多，緩存冗余越多，各緩存節(jié)點數(shù)據(jù)同步的原子性越難保證，一致性也就越難保證。第3種方式：采用定時拉取本身已經(jīng)放棄了數(shù)據(jù)的實時一致性。?所以我們在以下這幾種情況下拋棄進(jìn)程緩存，選用緩存服務(wù)：??1、Web集群下，包含多個實例，并且不允許業(yè)務(wù)數(shù)據(jù)的不一致性（我相信大部分業(yè)務(wù)不允許）2、進(jìn)程內(nèi)緩存數(shù)據(jù)量較大，緩存內(nèi)存空間不足，影響Web性能，可以考慮走緩存服務(wù)（緩存服務(wù)如redis，一般獨立服務(wù)甚至集群配置，支持超大量級）。3、評估value大小、緩存內(nèi)存空間、峰值QPS、過期時間、緩存命中率、讀寫更新策略、key值分布路由策略、過期策略以及數(shù)據(jù)一致性方案，根據(jù)實際需要判斷是否走緩存服務(wù)。??1、它支持復(fù)雜數(shù)據(jù)結(jié)構(gòu)value是字符串、哈希，列表，集合，有序集合這類復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。支持各種場景，如客戶訂單信息列表，用戶消息，帖子評論等。?
概述
我們所說的緩存分為進(jìn)程內(nèi)部緩存（系統(tǒng)內(nèi)部緩存）和 緩存服務(wù)（如redis/memcache）。計算機(jī)服務(wù)從原來的單體結(jié)構(gòu)，到多實例，到現(xiàn)在流行的微服務(wù)，緩存服務(wù)變得原來越流行了。??
進(jìn)程緩存
先說說進(jìn)程緩存，它將數(shù)據(jù)存儲在站點、服務(wù)的進(jìn)程內(nèi)。在Web的發(fā)展歷史上，這樣的方式備受歡迎。比如早期常用的.Net的? System.Web.Caching.這種實現(xiàn)載體很簡單，比如一個帶鎖的HasTable，或者一個List對象。使用簡單便捷，能存儲數(shù)據(jù)、html頁面片段、文件，甚至任何對象。在單體結(jié)構(gòu)的Web模式下，進(jìn)程內(nèi)緩存被開發(fā)到極致，大概流程如下圖：?與原先沒有緩存相比，進(jìn)程內(nèi)緩存的好處是，數(shù)據(jù)讀取不再直接訪問數(shù)據(jù)庫，先判斷緩存中是否存在，如果存在，則直接讀取，不存在則再去數(shù)據(jù)庫中取，同時寫入緩存。這樣避免了每次的請求都走數(shù)據(jù)庫，減少網(wǎng)絡(luò)開銷和數(shù)據(jù)請求次數(shù)，提高了數(shù)據(jù)獲取效率，基本等同在內(nèi)存中執(zhí)行。緩存的目的是為了冷熱數(shù)據(jù)的隔離，對于頻繁被修改的數(shù)據(jù)，緩存的意義不是很大，比如微信用戶的實時步數(shù)。比較有價值的是那些不被頻繁修改且數(shù)據(jù)量較大的內(nèi)容，比如系統(tǒng)字典、配置數(shù)據(jù)。判斷是否需要創(chuàng)建緩存需要一定的依據(jù)，以下是我的團(tuán)隊的策略，不一定適用，可以參考：緩存的必要性：數(shù)據(jù)的變更是否過于頻繁，過于頻繁則可能導(dǎo)致緩存不斷重建，反而降低效率。評估方式：緩存的過期時間內(nèi)沒被主動更新的量值應(yīng)該超過60%。假設(shè)緩存時間：3600s假設(shè)同一種類型緩存數(shù)據(jù)基數(shù)：6000個?6000 * 60% = 3600 的數(shù)據(jù)在一個小時內(nèi)事務(wù)未更新，這樣的緩存價值更大。?
進(jìn)程緩存的問題
在互聯(lián)網(wǎng)大潮下，隨著用戶量的激增，原來單體結(jié)構(gòu)逐漸的向Web服務(wù)集群發(fā)展，在多實例目標(biāo)下，進(jìn)程緩存的弊端越來越明顯。比如緩存無法統(tǒng)一的問題。如果站點和服務(wù)中的多個節(jié)點訪問統(tǒng)一的緩存服務(wù)（比如redis 或者 memerche），數(shù)據(jù)統(tǒng)一存儲，數(shù)據(jù)的一致性就比較容易保障。但如果是進(jìn)程緩存，數(shù)據(jù)存儲在站點和服務(wù)的多個節(jié)點內(nèi)，每個節(jié)點一個緩存，存儲多份，一致性就比較難保障。??如上圖，但是有個問題，Cache1、Cache1、Cache3一致性難以保障，如果想保持緩存的一致性時，該怎么辦呢？一般有以下幾種方法：1、單一服務(wù)節(jié)點通知其他服務(wù)節(jié)點，如果我們只是Web Service1 在執(zhí)行業(yè)務(wù)操作的時候修改數(shù)據(jù)庫，更新緩存，同時通知其他Web Service服務(wù)，其他Web Service 接收到信息的時候，進(jìn)行緩存更新。??2、 啟動MQ通知其他節(jié)點：如下圖，可以通過MQ通知其他節(jié)點。寫請求發(fā)生在server1，在修改完自己緩存數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)之后，給MQ生產(chǎn)數(shù)據(jù)變化通知，server2和server1訂閱MQ消息，當(dāng)消費(fèi)到MQ信息的時候，也修改緩存數(shù)據(jù)。?3、有一種簡單的方式，也可以解耦與Web Server的關(guān)系，就是直接放棄了“實時一致性”，啟動一個獨立的進(jìn)程服務(wù)，定時從后端拉取最新的數(shù)據(jù)，更新內(nèi)存緩存。?上述的幾種方法為了保持?jǐn)?shù)據(jù)的一致性，增加了一定的開銷，一方面緩存數(shù)據(jù)同步過程中會有出錯的風(fēng)險；另一方面實際上違背了緩存的原則：冷熱數(shù)據(jù)隔絕，有效的利用冷數(shù)據(jù)，減輕數(shù)據(jù)庫壓力，提升效率。如果緩存被頻繁修改或者同步，那緩存的價值就不大了。??補(bǔ)充：1、2 兩種方式，實例越多，緩存冗余越多，各緩存節(jié)點數(shù)據(jù)同步的原子性越難保證，一致性也就越難保證。第3種方式：采用定時拉取本身已經(jīng)放棄了數(shù)據(jù)的實時一致性。?所以我們在以下這幾種情況下拋棄進(jìn)程緩存，選用緩存服務(wù)：??1、Web集群下，包含多個實例，并且不允許業(yè)務(wù)數(shù)據(jù)的不一致性（我相信大部分業(yè)務(wù)不允許）2、進(jìn)程內(nèi)緩存數(shù)據(jù)量較大，緩存內(nèi)存空間不足，影響Web性能，可以考慮走緩存服務(wù)（緩存服務(wù)如redis，一般獨立服務(wù)甚至集群配置，支持超大量級）。3、評估value大小、緩存內(nèi)存空間、峰值QPS、過期時間、緩存命中率、讀寫更新策略、key值分布路由策略、過期策略以及數(shù)據(jù)一致性方案，根據(jù)實際需要判斷是否走緩存服務(wù)。?緩存服務(wù)
在互聯(lián)網(wǎng)分層架構(gòu)中，最常用的kv結(jié)構(gòu)的緩存是redis。他有如下特點：?1、它支持復(fù)雜數(shù)據(jù)結(jié)構(gòu)value是字符串、哈希，列表，集合，有序集合這類復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。支持各種場景，如客戶訂單信息列表，用戶消息，帖子評論等。?
下載文檔
