真實(shí)案例解析緩存大熱key的致命陷阱
引言
在現(xiàn)代軟件架構(gòu)中，緩存是提高系統(tǒng)性能和響應(yīng)速度的重要手段。然而，如果不正確地使用緩存，可能會(huì)導(dǎo)致嚴(yán)重的線上事故，尤其是緩存的大熱key問(wèn)題更是老生常談。本文將探討一個(gè)常見(jiàn)但容易被忽視的問(wèn)題：緩存大熱key和緩存擊穿問(wèn)題。我們將從一個(gè)真實(shí)案例入手，分析其原因，并提供解決方案和預(yù)防措施。
案例描述
某系統(tǒng)在雙十一大促期間，遇到了一個(gè)嚴(yán)重的線上事故。業(yè)務(wù)人員在創(chuàng)建一個(gè)大型活動(dòng)，該大型活動(dòng)由于活動(dòng)條件和活動(dòng)獎(jiǎng)勵(lì)比較多，導(dǎo)致生成的緩存內(nèi)容非常大。活動(dòng)上線后，系統(tǒng)就開(kāi)始出現(xiàn)各種異常告警，核心UMP監(jiān)控可用率由100%持續(xù)下降到20%，系統(tǒng)訪問(wèn)Redis的調(diào)用次數(shù)和查詢性能也斷崖式下降，后續(xù)更是產(chǎn)生連鎖反應(yīng)影響了其他多個(gè)核心接口的可用率，導(dǎo)致整個(gè)系統(tǒng)服務(wù)不可用。
原因分析
在這個(gè)系統(tǒng)中，為了提高查詢活動(dòng)的性能，我們開(kāi)發(fā)團(tuán)隊(duì)決定使用Redis作為緩存系統(tǒng)。將每個(gè)活動(dòng)信息作為一個(gè)key-value存儲(chǔ)在Redis中。由于業(yè)務(wù)需要，有時(shí)候業(yè)務(wù)運(yùn)營(yíng)人員也會(huì)創(chuàng)建一個(gè)非常龐大的活動(dòng)，來(lái)支撐雙十一期間的各種玩法。針對(duì)這種龐大的活動(dòng)，我們開(kāi)發(fā)團(tuán)隊(duì)也提前預(yù)料到了可能會(huì)出現(xiàn)的大key和熱key問(wèn)題，所以在查詢活動(dòng)緩存之前增加了一層本地jvm緩存，本地jvm緩存5分鐘，緩存失效后再去回源查詢Redis中的活動(dòng)緩存，本以為會(huì)萬(wàn)無(wú)一失，沒(méi)想到最后還是出了問(wèn)題。
圖片
查詢方法偽代碼
ActivityCache present = activityLocalCache.getIfPresent(activityDetailCacheKey);
if (present != null) {
ActivityCache activityCache = incentiveActivityPOConvert.copyActivityCache(present);
return activityCache
}
ActivityCache remoteCache = getCacheFromRedis(activityDetailCacheKey);
activityLocalCache.put(activityDetailCacheKey, remoteCache);
return remoteCache;查詢活動(dòng)緩存流程如上圖所示，為什么加了本地緩存還是出了問(wèn)題？
這里其實(shí)就存在著第一個(gè)緩存陷阱：緩存擊穿問(wèn)題。首先解釋一下什么是緩存擊穿；緩存擊穿（Cache Miss）是指在高并發(fā)的系統(tǒng)中，如果某個(gè)緩存鍵對(duì)應(yīng)的值在緩存中不存在（即緩存失效），那么所有請(qǐng)求都會(huì)直接訪問(wèn)后端數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)的負(fù)載瞬間增加，可能會(huì)引發(fā)數(shù)據(jù)庫(kù)宕機(jī)或服務(wù)不可用的情況。所以在本次事故里邊，運(yùn)營(yíng)人員審批活動(dòng)上線的一瞬間，活動(dòng)緩存只是寫(xiě)入到了Redis緩存中，但是本地緩存還都是空的，所以此時(shí)就會(huì)有大量請(qǐng)求來(lái)同時(shí)訪問(wèn)Redis。
按照以往經(jīng)驗(yàn)，Redis緩存都是純內(nèi)存操作，查詢性能可以滿足大量請(qǐng)求同時(shí)查詢活動(dòng)緩存，就在此時(shí)我們卻陷入了第二個(gè)緩存陷阱：網(wǎng)絡(luò)帶寬瓶頸；Redis的高并發(fā)性能毋庸置疑，但是我們卻忽略了一個(gè)大key和熱key對(duì)網(wǎng)絡(luò)帶寬的影響，本次引發(fā)問(wèn)題的大熱key大小達(dá)到了1.5M，經(jīng)過(guò)事后了解京東Redis對(duì)單分片的網(wǎng)絡(luò)帶寬也有限流，默認(rèn)200M，根據(jù)換算，該熱key最多只能支持133次的并發(fā)訪問(wèn)。所以就在活動(dòng)上線的同一時(shí)刻，加上緩存擊穿的影響，迅速達(dá)到了Redis單分片的帶寬限流閾值，導(dǎo)致Redis線程進(jìn)入阻塞狀態(tài)，以至于所有的業(yè)務(wù)服務(wù)器都無(wú)法查詢Redis緩存成功，最終引發(fā)了緩存雪崩效應(yīng)。
解決方案
為了解決這個(gè)問(wèn)題，開(kāi)發(fā)團(tuán)隊(duì)采取了以下措施：
- 大key治理：更換緩存對(duì)象序列化方法，由原來(lái)的JSON序列化調(diào)整為Protostuff序列化方式。治理效果：緩存對(duì)象大小由1.5M減少到了0.5M。
- 使用壓縮算法：在存儲(chǔ)緩存對(duì)象時(shí)，再使用壓縮算法（如gzip）對(duì)數(shù)據(jù)進(jìn)行壓縮,注意設(shè)置壓縮閾值，超過(guò)一定閾值后再進(jìn)行壓縮，以減少占用的內(nèi)存空間和網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量。壓縮效果：500k壓縮到了17k。
- 緩存回源優(yōu)化：本地緩存miss后回源查詢Redis增加線程鎖，減少回源Redis并發(fā)數(shù)量。
- 監(jiān)控和優(yōu)化Redis配置：定期監(jiān)控Redis網(wǎng)絡(luò)傳輸情況，根據(jù)實(shí)際情況調(diào)整Redis的限流配置，以確保Redis的穩(wěn)定運(yùn)行。
治理后業(yè)務(wù)偽代碼如下：
ActivityCache present = activityLocalCache.get(activityDetailCacheKey, key -> getCacheFromRedis(key));
if (present != null) {
return present;
}/**
* 查詢二進(jìn)制緩存
*
* @param activityDetailCacheBinKey
* @return
*/
private ActivityCache getBinCacheFromJimdb(String activityDetailCacheBinKey) {
List<byte[]> activityByteList = slaveCluster.hMget(activityDetailCacheBinKey.getBytes(),"stock".getBytes());
if (activityByteList.get(0) != null && activityByteList.get(0).length > 0) {
byte[] decompress = ByteCompressionUtil.decompress(activityByteList.get(0));
ActivityCache activityCache = ProtostuffUtil.deserialize(decompress, ActivityCache.class);
if (activityCache != null) {
if (activityByteList.get(1) != null && activityByteList.get(1).length > 0) {
activityCache.setAvailableStock(Integer.valueOf(new String(activityByteList.get(1))));
}
return activityCache;
}
}
return null;預(yù)防措施
為了避免類似的問(wèn)題再次發(fā)生，開(kāi)發(fā)團(tuán)隊(duì)采取了以下預(yù)防措施：
- 設(shè)計(jì)階段考慮緩存策略：在系統(tǒng)設(shè)計(jì)階段，充分考慮緩存的使用場(chǎng)景和數(shù)據(jù)特性，避免盲目使用大key緩存。
- 進(jìn)行壓力測(cè)試和性能評(píng)估：在上線前，進(jìn)行充分的壓力測(cè)試和性能評(píng)估，模擬高并發(fā)和大數(shù)據(jù)量的情況，及時(shí)發(fā)現(xiàn)和解決潛在問(wèn)題。
- 定期進(jìn)行系統(tǒng)優(yōu)化和升級(jí)：隨著業(yè)務(wù)的發(fā)展和技術(shù)的進(jìn)步，定期對(duì)系統(tǒng)進(jìn)行優(yōu)化和升級(jí)，引入新的技術(shù)和工具來(lái)提高系統(tǒng)的性能和穩(wěn)定性。
結(jié)論
緩存大key和熱key是緩存使用中常見(jiàn)的陷阱，千萬(wàn)不要心存僥幸，否則會(huì)引發(fā)嚴(yán)重的線上事故。通過(guò)本文的案例分析和解決方案，我們希望能夠幫助讀者更好地理解和應(yīng)對(duì)這個(gè)問(wèn)題。記住，合理使用緩存是提高系統(tǒng)性能的關(guān)鍵，而不是簡(jiǎn)單地將所有數(shù)據(jù)都存儲(chǔ)在緩存中。
