概述
我們所說的緩存分為進程內(nèi)部緩存(系統(tǒng)內(nèi)部緩存)和緩存服務(wù)(如redis/memcache)。
計算機服務(wù)從原來的單體結(jié)構(gòu),到多實例,到現(xiàn)在流行的微服務(wù),緩存服務(wù)變得原來越流行了。
進程緩存
先說說進程緩存,它將數(shù)據(jù)存儲在站點、服務(wù)的進程內(nèi)。在Web的發(fā)展歷史上,這樣的方式備受歡迎。比如早期常用的.Net的 System.Web.Caching.
這種實現(xiàn)載體很簡單,比如一個帶鎖的HasTable,或者一個List對象。使用簡單便捷,能存儲數(shù)據(jù)、html頁面片段、文件,甚至任何對象。
在單體結(jié)構(gòu)的Web模式下,進程內(nèi)緩存被開發(fā)到極致,大概流程如下圖:
與原先沒有緩存相比,進程內(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ù),以下是我的團隊的策略,不一定適用,可以參考:
緩存的必要性:數(shù)據(jù)的變更是否過于頻繁,過于頻繁則可能導(dǎo)致緩存不斷重建,反而降低效率。評估方式:緩存的過期時間內(nèi)沒被主動更新的量值應(yīng)該超過60%。
假設(shè)緩存時間:3600s
假設(shè)同一種類型緩存數(shù)據(jù)基數(shù):6000個
6000 * 60% = 3600 的數(shù)據(jù)在一個小時內(nèi)事務(wù)未更新,這樣的緩存價值更大。
進程緩存的問題
在互聯(lián)網(wǎng)大潮下,隨著用戶量的激增,原來單體結(jié)構(gòu)逐漸的向Web服務(wù)集群發(fā)展,在多實例目標(biāo)下,進程緩存的弊端越來越明顯。
比如緩存無法統(tǒng)一的問題。
如果站點和服務(wù)中的多個節(jié)點訪問統(tǒng)一的緩存服務(wù)(比如redis 或者 memerche),數(shù)據(jù)統(tǒng)一存儲,數(shù)據(jù)的一致性就比較容易保障。
但如果是進程緩存,數(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 接收到信息的時候,進行緩存更新。
2、 啟動MQ通知其他節(jié)點:如下圖,可以通過MQ通知其他節(jié)點。寫請求發(fā)生在server1,在修改完自己緩存數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)之后,給MQ生產(chǎn)數(shù)據(jù)變化通知,server2和server1訂閱MQ消息,當(dāng)消費到MQ信息的時候,也修改緩存數(shù)據(jù)。
3、有一種簡單的方式,也可以解耦與Web Server的關(guān)系,就是直接放棄了“實時一致性”,啟動一個獨立的進程服務(wù),定時從后端拉取最新的數(shù)據(jù),更新內(nèi)存緩存。
上述的幾種方法為了保持?jǐn)?shù)據(jù)的一致性,增加了一定的開銷,一方面緩存數(shù)據(jù)同步過程中會有出錯的風(fēng)險;另一方面實際上違背了緩存的原則:冷熱數(shù)據(jù)隔絕,有效的利用冷數(shù)據(jù),減輕數(shù)據(jù)庫壓力,提升效率。如果緩存被頻繁修改或者同步,那緩存的價值就不大了。
補充:1、2 兩種方式,實例越多,緩存冗余越多,各緩存節(jié)點數(shù)據(jù)同步的原子性越難保證,一致性也就越難保證。
第3種方式:采用定時拉取本身已經(jīng)放棄了數(shù)據(jù)的實時一致性。
所以我們在以下這幾種情況下拋棄進程緩存,選用緩存服務(wù):
1、Web集群下,包含多個實例,并且不允許業(yè)務(wù)數(shù)據(jù)的不一致性(我相信大部分業(yè)務(wù)不允許)
2、進程內(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)。支持各種場景,如客戶訂單信息列表,用戶消息,帖子評論等。
2、支持持久化
首先,redis的所有數(shù)據(jù)都是保存在內(nèi)存中,然后不定期的通過異步方式保存到磁盤上(這稱為“半持久化模式”);
也可以把每一次數(shù)據(jù)變化都寫入到一個append only file(aof)里面(這稱為“全持久化模式”,效率會低一點)。
但是我們盡量不要把redis當(dāng)作數(shù)據(jù)庫用,如果真的需要持久化數(shù)據(jù),建議可以走MySQL:
2.1、redis的定期快照不能保證數(shù)據(jù)不丟失
2.2、redis的AOF會降低效率,并且不能支持太大的數(shù)據(jù)量
3、具備高可用特性
Redis天然支持集群功能,可以實現(xiàn)主動復(fù)制,讀寫分離。官方也提供了sentinel集群管理工具,能夠?qū)崿F(xiàn)主從服務(wù)監(jiān)控,故障自動轉(zhuǎn)移。
4、存儲的內(nèi)容比較大
String類型:一個String類型的value最大可以存儲512M,List、Set、Hash類型:list的元素個數(shù)最多為2^32-1個,也就是4294967295個。
5、 支持事務(wù)
操作都是原子性,對數(shù)據(jù)的更改要么全部執(zhí)行,要么全部不執(zhí)行。避免業(yè)務(wù)數(shù)據(jù)的不一致性。
緩存使用注意
1、Web服務(wù) 單體模式轉(zhuǎn)為多實例之后,我們將進程緩存升級為緩存服務(wù)(redis),清清理了所有的緩存使用,都改成了對接redis。但是有一些地方漏掉,因為我們有3個實例,所以漏掉的那幾個地方,一旦修改某個數(shù)據(jù)之后,一會兒是新值,一會兒舊值,很神奇。
2、謹(jǐn)防緩存擊穿、雪崩的產(chǎn)生,這個我們有慘痛的教訓(xùn),后續(xù)來一篇專門分析下。
原文地址:https://mp.weixin.qq.com/s/14fgPS8V-9i5aNVHemBpSQ