緩存實(shí)戰(zhàn)：分布式鎖與穿透擊穿雪崩治理)
簡(jiǎn)介面向畢業(yè)設(shè)計(jì)與高并發(fā)緩存實(shí)戰(zhàn)的完整Redis項(xiàng)目資源適合希望深入掌握Redis核心原理、緩存策略與高并發(fā)場(chǎng)景落地的開(kāi)發(fā)者。壓縮包共79個(gè)文件以72個(gè)Java源碼類文件為主同時(shí)包含XML配置文件、Lua腳本、YAML配置與SQL初始化腳本整體體積僅93KB結(jié)構(gòu)緊湊、模塊邊界清晰。項(xiàng)目?jī)?nèi)容覆蓋常用數(shù)據(jù)結(jié)構(gòu)、RDB與AOF持久化機(jī)制、消息發(fā)布訂閱、事務(wù)與管道操作以及集群的搭建和數(shù)據(jù)分片策略同時(shí)按實(shí)際業(yè)務(wù)完成了緩存系統(tǒng)從架構(gòu)設(shè)計(jì)、編碼實(shí)現(xiàn)到壓測(cè)驗(yàn)證的完整閉環(huán)。通過(guò)該項(xiàng)目可掌握高并發(fā)環(huán)境下的緩存讀寫(xiě)優(yōu)化、數(shù)據(jù)庫(kù)壓力緩解和系統(tǒng)橫向擴(kuò)容方法為畢業(yè)設(shè)計(jì)或工程實(shí)踐提供可直接參考的完整樣例。目前已有48人學(xué)習(xí)適合正在準(zhǔn)備課設(shè)、畢設(shè)或面試的開(kāi)發(fā)者系統(tǒng)學(xué)習(xí)。1. 基于Redis實(shí)戰(zhàn)的高并發(fā)緩存項(xiàng)目在解決什么問(wèn)題不是把數(shù)據(jù)放進(jìn)內(nèi)存就完事秒殺剛開(kāi)始的一瞬間幾萬(wàn)個(gè)請(qǐng)求同時(shí)打向商品詳情頁(yè)如果每次都回源數(shù)據(jù)庫(kù)連接池幾秒就會(huì)被榨干接口延遲從幾十毫秒一路退化成超時(shí)。基于Redis實(shí)戰(zhàn)的高并發(fā)緩存項(xiàng)目練的就是這件事把熱點(diǎn)讀的壓力擋在數(shù)據(jù)庫(kù)前面同時(shí)保證緩存與數(shù)據(jù)庫(kù)最終一致。它把一條完整落地鏈路拆成可執(zhí)行步驟——Redis安裝與配置、數(shù)據(jù)類型選型、過(guò)期淘汰策略、分布式鎖、緩存穿透/擊穿/雪崩治理再到JMeter壓測(cè)和集群選型。適合正在準(zhǔn)備后端面試的Java工程師也適合在業(yè)務(wù)里被緩存一致性和緩存失效問(wèn)題追著跑的人。照著復(fù)現(xiàn)一遍等于提前踩完了高并發(fā)緩存最常見(jiàn)的坑。2. 先搭起高并發(fā)緩存的最小骨架環(huán)境、數(shù)據(jù)類型與過(guò)期機(jī)制高并發(fā)緩存項(xiàng)目不能一上來(lái)就上集群先把單機(jī)跑順。我一般先把本機(jī)或一臺(tái)測(cè)試機(jī)的Redis拉起來(lái)把讀寫(xiě)鏈路跑通再去談分布式鎖和緩存治理。不在單機(jī)階段把數(shù)據(jù)類型、過(guò)期策略和序列化方式定好后面壓測(cè)一打全是臟數(shù)據(jù)排錯(cuò)成本極高。2.1 本地快速拉起一個(gè)Redis安裝命令、核心配置與可視化工具常見(jiàn)做法是在Linux服務(wù)器上裝Redis。測(cè)試環(huán)境圖省事可以用包管理器但建議至少用源碼方式裝一次方便鎖定版本和看編譯輸出# Ubuntu / Debian 系快速安裝 sudo apt-get update sudo apt-get install -y redis-server # 源碼安裝便于指定版本 wget https://download.redis.io/releases/redis-7.0.14.tar.gz tar xzf redis-7.0.14.tar.gz cd redis-7.0.14 make sudo make install編譯通過(guò)后先前臺(tái)啟動(dòng)一次確認(rèn)沒(méi)有報(bào)錯(cuò)再轉(zhuǎn)后臺(tái)redis-server。生產(chǎn)習(xí)慣是用配置方式啟動(dòng)redis-server /etc/redis/redis.conf。源碼編譯的Redis默認(rèn)不帶systemd腳本我用nohup redis-server 起測(cè)試實(shí)例線上則用systemd或容器托管。拿到一個(gè)能跑的Redis后先改四個(gè)參數(shù)避免后患。打開(kāi)redis.conf把監(jiān)聽(tīng)地址、密碼、內(nèi)存上限和持久化策略一次調(diào)好# 綁定內(nèi)網(wǎng)網(wǎng)卡不要裸暴露到公網(wǎng) bind 127.0.0.1 192.168.1.100 # 生產(chǎn)環(huán)境必須設(shè)密碼 requirepass yourstrongpassword # 內(nèi)存上限防止OOM把整個(gè)機(jī)器拖死 maxmemory 2gb maxmemory-policy allkeys-lru # RDB AOF 雙開(kāi)注意性能和安全的取舍 appendonly yes appendfsync everysecbind只允許本機(jī)和內(nèi)網(wǎng)IP訪問(wèn)是防止緩存被外部掃描的第一道門(mén)。requirepass不設(shè)的話Redis基本等于裸奔。maxmemory設(shè)成物理內(nèi)存的一半左右避免Redis吃滿內(nèi)存后觸發(fā)系統(tǒng)OOM Killer。appendfsync everysec是性能和安全的中間值always太慢no容易丟數(shù)據(jù)。排查數(shù)據(jù)寫(xiě)沒(méi)寫(xiě)進(jìn)去時(shí)不一定非開(kāi)可視化工具。我習(xí)慣先用redis-cli直接敲命令驗(yàn)證redis-cli -a $REDIS_PWD GET product:1001。要看某個(gè)key多久過(guò)期用TTL product:1001要看哪些key占內(nèi)存大用redis-cli --bigkeys?？梢暬ぞ哂脕?lái)觀察整體結(jié)構(gòu)更直觀Redis Desktop Manager和Another Redis Desktop Manager都可以我一般拿它看key前綴分布和過(guò)期情況不會(huì)拿它做線上寫(xiě)操作。2.2 用Spring Boot寫(xiě)最小緩存讀寫(xiě)String、Hash還是對(duì)象序列化后端整合Redis常見(jiàn)做法是用Spring Boot的spring-boot-starter-data-redis。先配置連接池和序列化方式spring: data: redis: host: 127.0.0.1 port: 6379 password: ${REDIS_PWD} timeout: 3s lettuce: pool: max-active: 50 max-idle: 20 min-idle: 5 max-wait: 300ms連接池參數(shù)里max-active是核心。50個(gè)連接應(yīng)對(duì)單機(jī)壓測(cè)夠用但注意這只是上限不是初始值。min-idle設(shè)5避免流量突增時(shí)臨時(shí)創(chuàng)建連接產(chǎn)生延遲。timeout設(shè)3秒防止Redis阻塞時(shí)客戶端無(wú)限等待。讀寫(xiě)代碼我傾向于用StringRedisTemplate而不是RedisTemplate。RedisTemplate默認(rèn)的JDK序列化會(huì)把key和value都變成一串\xAC\xED開(kāi)頭的亂碼調(diào)試和排查都很難受。StringRedisTemplate把一切當(dāng)字符串處理配合JSON做序列化最直接Service public class ProductCacheService { private final StringRedisTemplate stringRedisTemplate; private final ObjectMapper objectMapper new ObjectMapper(); public Product getProduct(Long id) throws JsonProcessingException { String key product:detail: id; String json stringRedisTemplate.opsForValue().get(key); if (json ! null) { return objectMapper.readValue(json, Product.class); } // 未命中緩存回源數(shù)據(jù)庫(kù) Product product loadFromDb(id); if (product ! null) { stringRedisTemplate.opsForValue().set(key, objectMapper.writeValueAsString(product), Duration.ofMinutes(30)); } return product; } }這里set操作帶了Duration等于同時(shí)把TTL設(shè)好比先set再expire少一次網(wǎng)絡(luò)往返。為什么用String因?yàn)镴SON可讀、跨語(yǔ)言、方便排查線上出問(wèn)題能用肉眼看出value格式對(duì)不對(duì)。Hash則更適合熱更新場(chǎng)景比如商品詳情只改價(jià)格字段時(shí)用Hash的HSET product:hash:1001 price 99.9只寫(xiě)一個(gè)字段而不是把整個(gè)JSON拿出來(lái)反序列化再寫(xiě)回去。數(shù)據(jù)類型選擇原則很簡(jiǎn)單讀多寫(xiě)少用String字段級(jí)更新頻繁用Hash計(jì)數(shù)場(chǎng)景用String加INCR命令。2.3 緩存過(guò)期與淘汰策略參數(shù)怎么定才不被流量打穿每個(gè)key設(shè)多長(zhǎng)TTL是高并發(fā)緩存項(xiàng)目里最考經(jīng)驗(yàn)的地方。太短緩存形同虛設(shè)太長(zhǎng)數(shù)據(jù)不新鮮。我一般按業(yè)務(wù)容忍度分四類業(yè)務(wù)場(chǎng)景TTL建議說(shuō)明熱點(diǎn)商品詳情30分鐘到2小時(shí)容忍短暫不新鮮驗(yàn)證碼5分鐘必須嚴(yán)格過(guò)期庫(kù)存計(jì)數(shù)不設(shè)TTL或30秒配合分布式鎖更新用戶會(huì)話信息2小時(shí)有活動(dòng)時(shí)滑動(dòng)續(xù)期注意TTL不能全員寫(xiě)死。一個(gè)商品詳情頁(yè)在零點(diǎn)整同時(shí)過(guò)期會(huì)引發(fā)一次微型雪崩。解決辦法是加隨機(jī)偏移我習(xí)慣在固定TTL基礎(chǔ)上加0到60秒的隨機(jī)值Duration ttl Duration.ofMinutes(30) .plus(Duration.ofMillis( ThreadLocalRandom.current().nextLong(0, 60_000)));maxmemory-policy決定內(nèi)存滿了之后誰(shuí)被淘汰。默認(rèn)noeviction在寫(xiě)新key時(shí)會(huì)直接報(bào)錯(cuò)絕對(duì)不能用在生產(chǎn)。我線上常用allkeys-lru讓Redis按最近最少使用淘汰對(duì)熱點(diǎn)讀場(chǎng)景最省心。volatile-lru只淘汰設(shè)置了TTL的key適合緩存和永久數(shù)據(jù)混用的實(shí)例。如果業(yè)務(wù)數(shù)據(jù)有明顯冷熱區(qū)分又不想手動(dòng)管理allkeys-lru是最省事的選擇。3. 真正扛高并發(fā)的關(guān)鍵分布式鎖與緩存穿透/擊穿/雪崩治理單機(jī)緩存跑通只是起點(diǎn)。真正讓高并發(fā)緩存項(xiàng)目值錢(qián)的是并發(fā)場(chǎng)景下的鎖和三類經(jīng)典問(wèn)題緩存穿透、緩存擊穿、緩存雪崩。這三個(gè)詞面試必問(wèn)線上也必踩我一個(gè)個(gè)拆開(kāi)講。3.1 用SETNX到Redisson改造分布式鎖三個(gè)參數(shù)定生死緩存重建場(chǎng)景里如果熱點(diǎn)key失效幾十個(gè)線程同時(shí)回源數(shù)據(jù)庫(kù)MySQL會(huì)瞬間被打滿。常見(jiàn)做法是給緩存重建加分布式鎖只允許一個(gè)線程回源其余線程等待后復(fù)用第一個(gè)線程寫(xiě)的緩存。先看Redis原生命令版本。Redis從2.6.12開(kāi)始SET命令可以把加鎖和過(guò)期一次完成# 返回OK代表?yè)屾i成功返回nil代表鎖已被占用 SET lock:product:1001 8f3b2c9e NX EX 30NX表示只有key不存在時(shí)才寫(xiě)入EX 30表示鎖自動(dòng)過(guò)期30秒。value一定不能寫(xiě)死要寫(xiě)一個(gè)隨機(jī)UUID這樣釋放鎖時(shí)能確認(rèn)是自己的鎖。釋放鎖不能直接DEL否則可能把別人剛搶到的鎖刪掉。要保證原子性用一段Lua腳本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end這段Lua先校驗(yàn)value是否對(duì)得上對(duì)得上才刪這是分布式鎖最基本的安全底線。但原生SETNX有個(gè)隱患如果業(yè)務(wù)執(zhí)行超過(guò)30秒鎖自己過(guò)期了第二個(gè)線程進(jìn)來(lái)第一個(gè)線程還沒(méi)執(zhí)行完鎖就形同虛設(shè)。我線上更推薦用Redisson它提供的watchdog機(jī)制會(huì)自動(dòng)續(xù)期默認(rèn)每10秒檢測(cè)一次鎖是否仍持有自動(dòng)把鎖有效期延長(zhǎng)到業(yè)務(wù)結(jié)束RLock lock redissonClient.getLock(lock:product:1001); boolean locked lock.tryLock(0, 30, TimeUnit.SECONDS); if (!locked) { throw new BizException(排隊(duì)中請(qǐng)稍后重試); } try { // 只允許一個(gè)線程回源重建緩存 Product product loadFromDb(id); stringRedisTemplate.opsForValue().set(key, productJson, Duration.ofMinutes(30)); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }tryLock三個(gè)參數(shù)分別是最長(zhǎng)等待時(shí)間、鎖租約時(shí)間、時(shí)間單位。最長(zhǎng)時(shí)間設(shè)0表示搶不到就立刻返回適合秒殺場(chǎng)景讓用戶排隊(duì)重試。租約時(shí)間設(shè)30秒業(yè)務(wù)超過(guò)這個(gè)時(shí)間鎖會(huì)釋放防止持有鎖的節(jié)點(diǎn)宕機(jī)后鎖和業(yè)務(wù)一起掛掉。用Redisson時(shí)注意加鎖操作本身也可能拋異常要放在try外面否則鎖初始化失敗會(huì)被當(dāng)成業(yè)務(wù)異常吞掉。3.2 緩存穿透、擊穿、雪崩的治理空緩存、互斥重建與隨機(jī)TTL緩存穿透是查詢一個(gè)根本不存在的數(shù)據(jù)比如惡意請(qǐng)求商品ID為-1的接口。緩存里沒(méi)有數(shù)據(jù)庫(kù)里也沒(méi)有每次請(qǐng)求都回源數(shù)據(jù)庫(kù)壓力直接爆表。解決思路是給不存在的key也寫(xiě)一個(gè)空緩存TTL設(shè)短一點(diǎn)比如30秒Product product loadFromDb(id); if (product null) { // 空緩存兜底防止穿透 stringRedisTemplate.opsForValue().set( product:detail: id, EMPTY, Duration.ofSeconds(30)); return null; }更徹底的做法是前置布隆過(guò)濾器把存在的ID放在過(guò)濾器里請(qǐng)求先過(guò)過(guò)濾器不在直接返回。布隆過(guò)濾器有誤判率參數(shù)一般設(shè)1%以內(nèi)就夠用。它的缺點(diǎn)是維護(hù)成本高新增商品要同步更新位圖適合ID范圍穩(wěn)定的場(chǎng)景。緩存擊穿是熱點(diǎn)key剛好過(guò)期大量請(qǐng)求同時(shí)打進(jìn)來(lái)。穿透是查不存在的數(shù)據(jù)擊穿是查存在但緩存剛好失效的數(shù)據(jù)。擊穿的標(biāo)準(zhǔn)解法是互斥鎖只有搶到鎖的線程回源其余線程短暫等待后重查緩存。我常用SET key value NX EX做輕量鎖比Redisson更輕適合單機(jī)壓測(cè)練手String lockKey lock:product:detail: id; Boolean ok stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(5)); if (Boolean.TRUE.equals(ok)) { try { Product product loadFromDb(id); stringRedisTemplate.opsForValue().set(cacheKey, json, Duration.ofMinutes(30)); } finally { stringRedisTemplate.delete(lockKey); } } else { // 沒(méi)搶到鎖的線程等50ms后重查緩存 Thread.sleep(50); return getProduct(id); }這個(gè)是遞歸重查緩存剛被重建第二次查詢就能命中。注意Thread.sleep時(shí)間不要超過(guò)鎖的過(guò)期時(shí)間否則緩存還沒(méi)建好鎖就沒(méi)了后續(xù)請(qǐng)求還是會(huì)回源。緩存雪崩比擊穿更廣是大批量key同時(shí)過(guò)期或Redis節(jié)點(diǎn)宕機(jī)。解決思路分散化TTL加隨機(jī)偏移應(yīng)對(duì)批量過(guò)期主從哨兵應(yīng)對(duì)單點(diǎn)故障服務(wù)端做多級(jí)緩存兜底本地進(jìn)程內(nèi)緩存扛第一波Redis扛第二波數(shù)據(jù)庫(kù)只接收穿透下來(lái)的請(qǐng)求。3.3 緩存與數(shù)據(jù)庫(kù)一致性先更新庫(kù)還是先刪緩存緩存項(xiàng)目繞不開(kāi)一致性。常見(jiàn)做法是Cache Aside旁路緩存讀的時(shí)候先讀緩存未命中回源數(shù)據(jù)庫(kù)再寫(xiě)緩存寫(xiě)的時(shí)候先更新數(shù)據(jù)庫(kù)再刪除緩存。刪除緩存而不是更新緩存原因有兩個(gè)。第一更新緩存意味著每次寫(xiě)請(qǐng)求都要寫(xiě)Redis如果數(shù)據(jù)庫(kù)更新頻率高緩存會(huì)被頻繁重寫(xiě)白白浪費(fèi)性能。第二并發(fā)更新同一個(gè)key后寫(xiě)的值可能覆蓋先寫(xiě)的緩存里存的東西和數(shù)據(jù)庫(kù)不一致。刪除緩存則讓下次讀請(qǐng)求自然回源重建收斂到正確值。那為什么不是先刪緩存再更新數(shù)據(jù)庫(kù)因?yàn)閮蓚€(gè)操作之間有一個(gè)時(shí)間窗口。線程A先刪緩存線程B讀到緩存為空回源剛好數(shù)據(jù)庫(kù)還是舊值把舊值寫(xiě)回緩存之后線程A才把新值更新到數(shù)據(jù)庫(kù)緩存就永久是臟的了。先更新數(shù)據(jù)庫(kù)再刪緩存雖然刪緩存前有一小段時(shí)間緩存是舊值但最終會(huì)被一次刪除糾正收斂速度快得多。這個(gè)方案并非完全沒(méi)有坑。如果刪除緩存失敗比如Redis命令超時(shí)緩存里還是舊值。線上通用做法是延遲雙刪更新數(shù)據(jù)庫(kù)后刪除緩存隔幾百毫秒再刪一次即使第一次刪除失敗還有第二次兜底。實(shí)際項(xiàng)目里我更建議把刪除緩存動(dòng)作做成可靠消息或本地任務(wù)表異步重試幾次。對(duì)一致性要求極高的賬務(wù)類數(shù)據(jù)不要走緩存直接走數(shù)據(jù)庫(kù)強(qiáng)一致緩存只服務(wù)讀多寫(xiě)少的數(shù)據(jù)。4. 用壓測(cè)把高并發(fā)緩存項(xiàng)目跑穿JMeter、Redis監(jiān)控與集群選型寫(xiě)代碼誰(shuí)都會(huì)但高并發(fā)項(xiàng)目跑不跑得住必須壓測(cè)說(shuō)了算。壓測(cè)不是簡(jiǎn)單開(kāi)幾個(gè)線程打一打要看緩存命中率、TPS拐點(diǎn)和慢日志變化。這一章講我把單機(jī)緩存項(xiàng)目驗(yàn)證到能上線的三板斧。4.1 用JMeter打高并發(fā)壓測(cè)線程組、聚合報(bào)告與三個(gè)必調(diào)參數(shù)JMeter是壓測(cè)高并發(fā)緩存項(xiàng)目的標(biāo)準(zhǔn)工具。常見(jiàn)做法是先用GUI把測(cè)試計(jì)劃配好再命令行跑回歸。線程組是最核心的組件參數(shù)直接影響壓測(cè)結(jié)果參數(shù)建議值作用線程數(shù)200到1000模擬并發(fā)用戶數(shù)Ramp-up30到60秒讓壓力緩慢爬升不要瞬間壓垮循環(huán)次數(shù)100到500保證每個(gè)線程有足夠請(qǐng)求量壓測(cè)需要把Redis緩存先預(yù)熱還是先清空看目標(biāo)而定。測(cè)緩存穿透我用redis-cli把相關(guān)key清空再打測(cè)綜合性能先灌一批熱點(diǎn)數(shù)據(jù)再打。JMeter加HTTP請(qǐng)求采樣器配置里把連接超時(shí)設(shè)為1000ms、響應(yīng)超時(shí)設(shè)為3000ms超過(guò)就當(dāng)成失敗這樣能暴露Redis慢命令的問(wèn)題。命令行跑壓測(cè)是上線前的固定動(dòng)作jmeter -n -t high-concurrency.jmx -l result.jtl -e -o report/跑完后重點(diǎn)看聚合報(bào)告里的三個(gè)數(shù)字吞吐量、90%響應(yīng)時(shí)間和異常率。吞吐量就是每秒能處理多少請(qǐng)求90%響應(yīng)時(shí)間反映用戶體驗(yàn)異常率超過(guò)0.1%就必須查日志。第一次壓測(cè)我一般只開(kāi)200并發(fā)觀察數(shù)據(jù)庫(kù)連接池和Redis內(nèi)存變化再逐步加到500、1000找到TPS拐點(diǎn)。4.2 Redis慢日志與INFO命令壓測(cè)時(shí)的三個(gè)監(jiān)控手段壓測(cè)過(guò)程中不能只盯著JMeterRedis側(cè)的監(jiān)控才決定瓶頸分析方向。我會(huì)同時(shí)開(kāi)三個(gè)終端分別跑慢日志、INFO統(tǒng)計(jì)和bigkeys掃描# 查看最近10條慢日志 redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PWD slowlog get 10 # 緩存命中率核心指標(biāo) redis-cli info stats | grep -E keyspace_hits|keyspace_misses # 各命令調(diào)用次數(shù)統(tǒng)計(jì)找出熱點(diǎn)命令 redis-cli info commandstats | head -30慢日志默認(rèn)閾值是10000微秒也就是10毫秒。壓測(cè)時(shí)如果發(fā)現(xiàn)大量命令超過(guò)這個(gè)閾值說(shuō)明Redis執(zhí)行被阻塞或key太大。INFO命令里keyspace_hits和keyspace_misses是緩存治理最核心的兩個(gè)數(shù)字命中率公式是hits除以hits加misses。線上運(yùn)營(yíng)正常時(shí)命中率低于80%就要警惕壓測(cè)時(shí)如果命中率驟降多半是緩存預(yù)熱不夠或者TTL設(shè)置不合理。--bigkeys掃描可以找出大key。一個(gè)value超過(guò)1MB的key在高并發(fā)下會(huì)成為熱點(diǎn)瓶頸讀寫(xiě)都慢。壓測(cè)前先跑一遍這個(gè)命令把大key拆掉或換數(shù)據(jù)結(jié)構(gòu)不然壓到一半Redis卡死會(huì)以為是代碼問(wèn)題。4.3 從單機(jī)到集群主從、哨兵和Cluster的邊界單機(jī)壓測(cè)通過(guò)后下一個(gè)問(wèn)題是走到哪一步要開(kāi)始上集群。常見(jiàn)做法分三檔。主從復(fù)制解決的是讀壓力。一臺(tái)master掛多臺(tái)slave讀流量分配到slavemaster只處理寫(xiě)。主從同步是異步的slave上可能有短暫數(shù)據(jù)延遲對(duì)一致性敏感的頁(yè)面不要走slave。哨兵模式解決的是高可用。master掛了哨兵自動(dòng)把slave提升為master應(yīng)用端通過(guò)哨兵感知新的master地址。但一臺(tái)master依然有內(nèi)存上限數(shù)據(jù)量超過(guò)單機(jī)內(nèi)存還是撐不住。Cluster模式解決的是容量和寫(xiě)擴(kuò)展。數(shù)據(jù)按slot均勻分布到多臺(tái)節(jié)點(diǎn)寫(xiě)入可以水平擴(kuò)展。Cluster的代價(jià)是客戶端復(fù)雜度高多key操作要確認(rèn)它們?cè)谕粋€(gè)slot事務(wù)能力也受限。我見(jiàn)過(guò)不少團(tuán)隊(duì)在數(shù)據(jù)量不到5GB時(shí)就上了Cluster運(yùn)維把slot遷移和reshard折騰得苦不堪言。我的建議是先壓測(cè)如果單機(jī)8GB內(nèi)存和哨兵模式能扛住未來(lái)一年的峰值就不要上Cluster。鎖和數(shù)據(jù)一致性復(fù)雜度不值得為不存在的高并發(fā)買(mǎi)單。5. 高并發(fā)緩存項(xiàng)目最容易翻車(chē)的5個(gè)坑現(xiàn)象、原因與解決高并發(fā)緩存項(xiàng)目做完壓測(cè)和上線過(guò)程會(huì)暴露一堆只靠讀文檔發(fā)現(xiàn)不了的問(wèn)題。下面這5條是我反復(fù)踩過(guò)、也幫別人排查過(guò)最多的坑每一條都按現(xiàn)象、原因、解決的順序拆開(kāi)講你可以直接對(duì)照自己的項(xiàng)目。5.1 并發(fā)一高數(shù)據(jù)庫(kù)連接池就報(bào)錯(cuò)緩存形同虛設(shè)現(xiàn)象壓測(cè)線程從200加到500時(shí)數(shù)據(jù)庫(kù)連接池開(kāi)始拋Connection is not available, request timed out但Redis的CPU和內(nèi)存都正常。原因查了下緩存的命中率發(fā)現(xiàn)大量請(qǐng)求在查一個(gè)不存在的ID比如商品ID為負(fù)數(shù)或者已被下架的數(shù)據(jù)。這些key緩存里沒(méi)有回源邏輯每次都查數(shù)據(jù)庫(kù)緩存完全沒(méi)有兜住。這是典型的緩存穿透惡意請(qǐng)求拿不存在的ID反復(fù)打接口時(shí)尤其嚴(yán)重。解決給查詢結(jié)果為空的情況寫(xiě)臨時(shí)緩存TTL設(shè)30秒同時(shí)在前置接口做參數(shù)校驗(yàn)負(fù)數(shù)ID直接返回異常。更穩(wěn)妥的方案是在緩存層加布隆過(guò)濾器ID不在集合里的請(qǐng)求直接丟棄不用碰數(shù)據(jù)庫(kù)。5.2 分布式鎖搶到了還是超賣(mài)庫(kù)存扣成負(fù)數(shù)現(xiàn)象壓測(cè)秒殺接口時(shí)庫(kù)存總數(shù)1000件實(shí)際賣(mài)出去1200件日志里每個(gè)線程都聲稱自己搶到了鎖。原因鎖沒(méi)搶到不等同于業(yè)務(wù)沒(méi)執(zhí)行。我把鎖的tryLock返回值當(dāng)成成功標(biāo)志但沒(méi)在失敗時(shí)終止流程線程繼續(xù)往下執(zhí)行扣庫(kù)存。另外一個(gè)更隱蔽的原因是鎖value寫(xiě)死了固定字符串線程A釋放鎖時(shí)把線程B的鎖也刪了。兩個(gè)線程同時(shí)持鎖超賣(mài)就必然發(fā)生。解決tryLock返回false必須直接拋異?；蚍祷亍皳屬?gòu)失敗”不能繼續(xù)往下走。釋放鎖改用Lua腳本比對(duì)value再刪除確保只能刪自己的鎖。用Redisson的話配置watchdog自動(dòng)續(xù)期避免業(yè)務(wù)執(zhí)行超過(guò)鎖租約時(shí)間。5.3 同期設(shè)置的緩存key在同一秒失效緩存命中率一夜回到解放前現(xiàn)象零點(diǎn)過(guò)后緩存命中率從95%暴跌到40%數(shù)據(jù)庫(kù)壓力暴漲持續(xù)一兩分鐘后才恢復(fù)?？碦edis慢日志大批KEYS命令和同前綴的GET命令同時(shí)出現(xiàn)。原因所有商品詳情key都是寫(xiě)入時(shí)固定加30分鐘TTL同一批商品在同一時(shí)間失效形成批量緩存雪崩。雖然Redis還活著但數(shù)據(jù)庫(kù)被回源流量打蒙了接口響應(yīng)時(shí)間翻了十倍。解決TTL不再寫(xiě)死寫(xiě)入時(shí)加隨機(jī)偏移讓過(guò)期時(shí)間分散在前后一分鐘內(nèi)。同時(shí)給熱點(diǎn)商品加一個(gè)主動(dòng)續(xù)期邏輯訪問(wèn)時(shí)如果TTL低于閾值就把TTL續(xù)到30分鐘相當(dāng)于給熱點(diǎn)數(shù)據(jù)續(xù)命。5.4 Redis可視化工具里全是亂碼value長(zhǎng)這樣\xAC\xED\x00\x05t現(xiàn)象用Redis Desktop Manager打開(kāi)緩存實(shí)例key顯示成\xAC\xED\x00\x05tProductvalue也是\xAC\xED\x00\x05開(kāi)頭的一串亂碼命令行里卻能看到業(yè)務(wù)字符串。原因RedisTemplate默認(rèn)使用JdkSerializationRedisSerializerJava對(duì)象先被JDK序列化成二進(jìn)制再存進(jìn)Redis。JDK序列化后的數(shù)據(jù)帶類型簽名可讀性極差還會(huì)在value里附帶類路徑占空間。這不是Redis的問(wèn)題是客戶端序列化方式選錯(cuò)了。解決統(tǒng)一改用StringRedisTemplatekey和value都存字符串。對(duì)象先轉(zhuǎn)JSON字符串再寫(xiě)入讀取時(shí)再反序列化。如果必須用RedisTemplate把valueSerializer替換成GenericJackson2JsonRedisSerializerkey保持StringRedisSerializer。改完后可視化工具和命令行看到的內(nèi)容都應(yīng)該是可讀JSON。5.5 Redis command timed outLettuce連接池被打滿現(xiàn)象高并發(fā)壓測(cè)時(shí)應(yīng)用日志頻繁報(bào)Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException幾分鐘后接口大面積超時(shí)。原因Lettuce作為Spring Boot默認(rèn)客戶端是異步的但如果connection pool配置不對(duì)它會(huì)把請(qǐng)求阻塞在等待連接上。我遇到過(guò)把max-idle設(shè)成8、max-active設(shè)成16的小池子壓到200并發(fā)時(shí)所有連接都被占滿新請(qǐng)求全部超時(shí)。另外一個(gè)原因是Redis側(cè)有慢命令比如處理很大的Hash單個(gè)命令耗時(shí)超過(guò)客戶端的timeout閾值。解決先把max-active調(diào)到壓測(cè)并發(fā)數(shù)以上的值比如500并發(fā)配80個(gè)連接max-wait設(shè)300到500毫秒。然后查Redis慢日志找到耗時(shí)超過(guò)客戶端timeout的命令拆大key或換數(shù)據(jù)結(jié)構(gòu)。如果業(yè)務(wù)對(duì)單點(diǎn)延遲敏感客戶端timeout和Redis慢日志閾值要同步調(diào)讓超時(shí)先于隊(duì)列堆積出現(xiàn)便于提前發(fā)現(xiàn)瓶頸。6. 緩存Key命名與上線前的自查習(xí)慣高并發(fā)緩存項(xiàng)目收尾時(shí)我堅(jiān)持做三件事key命名統(tǒng)一、TTL隨機(jī)化、上線前壓測(cè)。key命名我最常用的是“業(yè)務(wù):場(chǎng)景:ID:版本”格式比如mall:product:detail:1001:v2。業(yè)務(wù)前綴方便按產(chǎn)品線隔離場(chǎng)景前綴方便定位用途ID是具體數(shù)據(jù)版本號(hào)是給緩存結(jié)構(gòu)升級(jí)留的后路。用冒號(hào)而不是下劃線因?yàn)镽edis Desktop Manager和另一個(gè)可視化工具會(huì)把冒號(hào)自動(dòng)折疊成目錄樹(shù)排查效率高很多。上線前我有個(gè)固定checklist抽查高流量緩存key是不是都帶了隨機(jī)TTL偏移用redis-cli --bigkeys確認(rèn)沒(méi)有超過(guò)1MB的大key跑一次200并發(fā)的壓測(cè)看緩存命中率和慢日志有沒(méi)有異常確認(rèn)Redis可視化工具里能看到正常JSON而不是JDK序列化的亂碼。這套動(dòng)作看起來(lái)瑣碎但每次都能攔住至少一個(gè)上線事故。我的個(gè)人習(xí)慣是把線上緩存問(wèn)題當(dāng)成黑匣子來(lái)記錄什么時(shí)間點(diǎn)命中率下降、當(dāng)時(shí)連著做了多少次回源、Redis慢日志里是哪類命令記多了會(huì)發(fā)現(xiàn)大多數(shù)緩存事故的根源就那幾個(gè)。高并發(fā)緩存項(xiàng)目最大的價(jià)值不是把Redis用熟而是學(xué)會(huì)在數(shù)據(jù)庫(kù)被打爆之前靠監(jiān)控?cái)?shù)據(jù)把痛點(diǎn)定位出來(lái)。希望這些參數(shù)和踩坑記錄能幫你少走一段彎路希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取 基于Redis的高并發(fā)緩存實(shí)戰(zhàn)：分布式鎖與穿透擊穿雪崩治理
簡(jiǎn)介面向畢業(yè)設(shè)計(jì)與高并發(fā)緩存實(shí)戰(zhàn)的完整Redis項(xiàng)目資源適合希望深入掌握Redis核心原理、緩存策略與高并發(fā)場(chǎng)景落地的開(kāi)發(fā)者。壓縮包共79個(gè)文件以72個(gè)Java源碼類文件為主同時(shí)包含XML配置文件、Lua腳本、YAML配置與SQL初始化腳本整體體積僅93KB結(jié)構(gòu)緊湊、模塊邊界清晰。項(xiàng)目?jī)?nèi)容覆蓋常用數(shù)據(jù)結(jié)構(gòu)、RDB與AOF持久化機(jī)制、消息發(fā)布訂閱、事務(wù)與管道操作以及集群的搭建和數(shù)據(jù)分片策略同時(shí)按實(shí)際業(yè)務(wù)完成了緩存系統(tǒng)從架構(gòu)設(shè)計(jì)、編碼實(shí)現(xiàn)到壓測(cè)驗(yàn)證的完整閉環(huán)。通過(guò)該項(xiàng)目可掌握高并發(fā)環(huán)境下的緩存讀寫(xiě)優(yōu)化、數(shù)據(jù)庫(kù)壓力緩解和系統(tǒng)橫向擴(kuò)容方法為畢業(yè)設(shè)計(jì)或工程實(shí)踐提供可直接參考的完整樣例。目前已有48人學(xué)習(xí)適合正在準(zhǔn)備課設(shè)、畢設(shè)或面試的開(kāi)發(fā)者系統(tǒng)學(xué)習(xí)。1. 基于Redis實(shí)戰(zhàn)的高并發(fā)緩存項(xiàng)目在解決什么問(wèn)題不是把數(shù)據(jù)放進(jìn)內(nèi)存就完事秒殺剛開(kāi)始的一瞬間幾萬(wàn)個(gè)請(qǐng)求同時(shí)打向商品詳情頁(yè)如果每次都回源數(shù)據(jù)庫(kù)連接池幾秒就會(huì)被榨干接口延遲從幾十毫秒一路退化成超時(shí)。基于Redis實(shí)戰(zhàn)的高并發(fā)緩存項(xiàng)目練的就是這件事把熱點(diǎn)讀的壓力擋在數(shù)據(jù)庫(kù)前面同時(shí)保證緩存與數(shù)據(jù)庫(kù)最終一致。它把一條完整落地鏈路拆成可執(zhí)行步驟——Redis安裝與配置、數(shù)據(jù)類型選型、過(guò)期淘汰策略、分布式鎖、緩存穿透/擊穿/雪崩治理再到JMeter壓測(cè)和集群選型。適合正在準(zhǔn)備后端面試的Java工程師也適合在業(yè)務(wù)里被緩存一致性和緩存失效問(wèn)題追著跑的人。照著復(fù)現(xiàn)一遍等于提前踩完了高并發(fā)緩存最常見(jiàn)的坑。2. 先搭起高并發(fā)緩存的最小骨架環(huán)境、數(shù)據(jù)類型與過(guò)期機(jī)制高并發(fā)緩存項(xiàng)目不能一上來(lái)就上集群先把單機(jī)跑順。我一般先把本機(jī)或一臺(tái)測(cè)試機(jī)的Redis拉起來(lái)把讀寫(xiě)鏈路跑通再去談分布式鎖和緩存治理。不在單機(jī)階段把數(shù)據(jù)類型、過(guò)期策略和序列化方式定好后面壓測(cè)一打全是臟數(shù)據(jù)排錯(cuò)成本極高。2.1 本地快速拉起一個(gè)Redis安裝命令、核心配置與可視化工具常見(jiàn)做法是在Linux服務(wù)器上裝Redis。測(cè)試環(huán)境圖省事可以用包管理器但建議至少用源碼方式裝一次方便鎖定版本和看編譯輸出# Ubuntu / Debian 系快速安裝 sudo apt-get update sudo apt-get install -y redis-server # 源碼安裝便于指定版本 wget https://download.redis.io/releases/redis-7.0.14.tar.gz tar xzf redis-7.0.14.tar.gz cd redis-7.0.14 make sudo make install編譯通過(guò)后先前臺(tái)啟動(dòng)一次確認(rèn)沒(méi)有報(bào)錯(cuò)再轉(zhuǎn)后臺(tái)redis-server。生產(chǎn)習(xí)慣是用配置方式啟動(dòng)redis-server /etc/redis/redis.conf。源碼編譯的Redis默認(rèn)不帶systemd腳本我用nohup redis-server 起測(cè)試實(shí)例線上則用systemd或容器托管。拿到一個(gè)能跑的Redis后先改四個(gè)參數(shù)避免后患。打開(kāi)redis.conf把監(jiān)聽(tīng)地址、密碼、內(nèi)存上限和持久化策略一次調(diào)好# 綁定內(nèi)網(wǎng)網(wǎng)卡不要裸暴露到公網(wǎng) bind 127.0.0.1 192.168.1.100 # 生產(chǎn)環(huán)境必須設(shè)密碼 requirepass yourstrongpassword # 內(nèi)存上限防止OOM把整個(gè)機(jī)器拖死 maxmemory 2gb maxmemory-policy allkeys-lru # RDB AOF 雙開(kāi)注意性能和安全的取舍 appendonly yes appendfsync everysecbind只允許本機(jī)和內(nèi)網(wǎng)IP訪問(wèn)是防止緩存被外部掃描的第一道門(mén)。requirepass不設(shè)的話Redis基本等于裸奔。maxmemory設(shè)成物理內(nèi)存的一半左右避免Redis吃滿內(nèi)存后觸發(fā)系統(tǒng)OOM Killer。appendfsync everysec是性能和安全的中間值always太慢no容易丟數(shù)據(jù)。排查數(shù)據(jù)寫(xiě)沒(méi)寫(xiě)進(jìn)去時(shí)不一定非開(kāi)可視化工具。我習(xí)慣先用redis-cli直接敲命令驗(yàn)證redis-cli -a $REDIS_PWD GET product:1001。要看某個(gè)key多久過(guò)期用TTL product:1001要看哪些key占內(nèi)存大用redis-cli --bigkeys?？梢暬ぞ哂脕?lái)觀察整體結(jié)構(gòu)更直觀Redis Desktop Manager和Another Redis Desktop Manager都可以我一般拿它看key前綴分布和過(guò)期情況不會(huì)拿它做線上寫(xiě)操作。2.2 用Spring Boot寫(xiě)最小緩存讀寫(xiě)String、Hash還是對(duì)象序列化后端整合Redis常見(jiàn)做法是用Spring Boot的spring-boot-starter-data-redis。先配置連接池和序列化方式spring: data: redis: host: 127.0.0.1 port: 6379 password: ${REDIS_PWD} timeout: 3s lettuce: pool: max-active: 50 max-idle: 20 min-idle: 5 max-wait: 300ms連接池參數(shù)里max-active是核心。50個(gè)連接應(yīng)對(duì)單機(jī)壓測(cè)夠用但注意這只是上限不是初始值。min-idle設(shè)5避免流量突增時(shí)臨時(shí)創(chuàng)建連接產(chǎn)生延遲。timeout設(shè)3秒防止Redis阻塞時(shí)客戶端無(wú)限等待。讀寫(xiě)代碼我傾向于用StringRedisTemplate而不是RedisTemplate。RedisTemplate默認(rèn)的JDK序列化會(huì)把key和value都變成一串\xAC\xED開(kāi)頭的亂碼調(diào)試和排查都很難受。StringRedisTemplate把一切當(dāng)字符串處理配合JSON做序列化最直接Service public class ProductCacheService { private final StringRedisTemplate stringRedisTemplate; private final ObjectMapper objectMapper new ObjectMapper(); public Product getProduct(Long id) throws JsonProcessingException { String key product:detail: id; String json stringRedisTemplate.opsForValue().get(key); if (json ! null) { return objectMapper.readValue(json, Product.class); } // 未命中緩存回源數(shù)據(jù)庫(kù) Product product loadFromDb(id); if (product ! null) { stringRedisTemplate.opsForValue().set(key, objectMapper.writeValueAsString(product), Duration.ofMinutes(30)); } return product; } }這里set操作帶了Duration等于同時(shí)把TTL設(shè)好比先set再expire少一次網(wǎng)絡(luò)往返。為什么用String因?yàn)镴SON可讀、跨語(yǔ)言、方便排查線上出問(wèn)題能用肉眼看出value格式對(duì)不對(duì)。Hash則更適合熱更新場(chǎng)景比如商品詳情只改價(jià)格字段時(shí)用Hash的HSET product:hash:1001 price 99.9只寫(xiě)一個(gè)字段而不是把整個(gè)JSON拿出來(lái)反序列化再寫(xiě)回去。數(shù)據(jù)類型選擇原則很簡(jiǎn)單讀多寫(xiě)少用String字段級(jí)更新頻繁用Hash計(jì)數(shù)場(chǎng)景用String加INCR命令。2.3 緩存過(guò)期與淘汰策略參數(shù)怎么定才不被流量打穿每個(gè)key設(shè)多長(zhǎng)TTL是高并發(fā)緩存項(xiàng)目里最考經(jīng)驗(yàn)的地方。太短緩存形同虛設(shè)太長(zhǎng)數(shù)據(jù)不新鮮。我一般按業(yè)務(wù)容忍度分四類業(yè)務(wù)場(chǎng)景TTL建議說(shuō)明熱點(diǎn)商品詳情30分鐘到2小時(shí)容忍短暫不新鮮驗(yàn)證碼5分鐘必須嚴(yán)格過(guò)期庫(kù)存計(jì)數(shù)不設(shè)TTL或30秒配合分布式鎖更新用戶會(huì)話信息2小時(shí)有活動(dòng)時(shí)滑動(dòng)續(xù)期注意TTL不能全員寫(xiě)死。一個(gè)商品詳情頁(yè)在零點(diǎn)整同時(shí)過(guò)期會(huì)引發(fā)一次微型雪崩。解決辦法是加隨機(jī)偏移我習(xí)慣在固定TTL基礎(chǔ)上加0到60秒的隨機(jī)值Duration ttl Duration.ofMinutes(30) .plus(Duration.ofMillis( ThreadLocalRandom.current().nextLong(0, 60_000)));maxmemory-policy決定內(nèi)存滿了之后誰(shuí)被淘汰。默認(rèn)noeviction在寫(xiě)新key時(shí)會(huì)直接報(bào)錯(cuò)絕對(duì)不能用在生產(chǎn)。我線上常用allkeys-lru讓Redis按最近最少使用淘汰對(duì)熱點(diǎn)讀場(chǎng)景最省心。volatile-lru只淘汰設(shè)置了TTL的key適合緩存和永久數(shù)據(jù)混用的實(shí)例。如果業(yè)務(wù)數(shù)據(jù)有明顯冷熱區(qū)分又不想手動(dòng)管理allkeys-lru是最省事的選擇。3. 真正扛高并發(fā)的關(guān)鍵分布式鎖與緩存穿透/擊穿/雪崩治理單機(jī)緩存跑通只是起點(diǎn)。真正讓高并發(fā)緩存項(xiàng)目值錢(qián)的是并發(fā)場(chǎng)景下的鎖和三類經(jīng)典問(wèn)題緩存穿透、緩存擊穿、緩存雪崩。這三個(gè)詞面試必問(wèn)線上也必踩我一個(gè)個(gè)拆開(kāi)講。3.1 用SETNX到Redisson改造分布式鎖三個(gè)參數(shù)定生死緩存重建場(chǎng)景里如果熱點(diǎn)key失效幾十個(gè)線程同時(shí)回源數(shù)據(jù)庫(kù)MySQL會(huì)瞬間被打滿。常見(jiàn)做法是給緩存重建加分布式鎖只允許一個(gè)線程回源其余線程等待后復(fù)用第一個(gè)線程寫(xiě)的緩存。先看Redis原生命令版本。Redis從2.6.12開(kāi)始SET命令可以把加鎖和過(guò)期一次完成# 返回OK代表?yè)屾i成功返回nil代表鎖已被占用 SET lock:product:1001 8f3b2c9e NX EX 30NX表示只有key不存在時(shí)才寫(xiě)入EX 30表示鎖自動(dòng)過(guò)期30秒。value一定不能寫(xiě)死要寫(xiě)一個(gè)隨機(jī)UUID這樣釋放鎖時(shí)能確認(rèn)是自己的鎖。釋放鎖不能直接DEL否則可能把別人剛搶到的鎖刪掉。要保證原子性用一段Lua腳本if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end這段Lua先校驗(yàn)value是否對(duì)得上對(duì)得上才刪這是分布式鎖最基本的安全底線。但原生SETNX有個(gè)隱患如果業(yè)務(wù)執(zhí)行超過(guò)30秒鎖自己過(guò)期了第二個(gè)線程進(jìn)來(lái)第一個(gè)線程還沒(méi)執(zhí)行完鎖就形同虛設(shè)。我線上更推薦用Redisson它提供的watchdog機(jī)制會(huì)自動(dòng)續(xù)期默認(rèn)每10秒檢測(cè)一次鎖是否仍持有自動(dòng)把鎖有效期延長(zhǎng)到業(yè)務(wù)結(jié)束RLock lock redissonClient.getLock(lock:product:1001); boolean locked lock.tryLock(0, 30, TimeUnit.SECONDS); if (!locked) { throw new BizException(排隊(duì)中請(qǐng)稍后重試); } try { // 只允許一個(gè)線程回源重建緩存 Product product loadFromDb(id); stringRedisTemplate.opsForValue().set(key, productJson, Duration.ofMinutes(30)); } finally { if (lock.isHeldByCurrentThread()) { lock.unlock(); } }tryLock三個(gè)參數(shù)分別是最長(zhǎng)等待時(shí)間、鎖租約時(shí)間、時(shí)間單位。最長(zhǎng)時(shí)間設(shè)0表示搶不到就立刻返回適合秒殺場(chǎng)景讓用戶排隊(duì)重試。租約時(shí)間設(shè)30秒業(yè)務(wù)超過(guò)這個(gè)時(shí)間鎖會(huì)釋放防止持有鎖的節(jié)點(diǎn)宕機(jī)后鎖和業(yè)務(wù)一起掛掉。用Redisson時(shí)注意加鎖操作本身也可能拋異常要放在try外面否則鎖初始化失敗會(huì)被當(dāng)成業(yè)務(wù)異常吞掉。3.2 緩存穿透、擊穿、雪崩的治理空緩存、互斥重建與隨機(jī)TTL緩存穿透是查詢一個(gè)根本不存在的數(shù)據(jù)比如惡意請(qǐng)求商品ID為-1的接口。緩存里沒(méi)有數(shù)據(jù)庫(kù)里也沒(méi)有每次請(qǐng)求都回源數(shù)據(jù)庫(kù)壓力直接爆表。解決思路是給不存在的key也寫(xiě)一個(gè)空緩存TTL設(shè)短一點(diǎn)比如30秒Product product loadFromDb(id); if (product null) { // 空緩存兜底防止穿透 stringRedisTemplate.opsForValue().set( product:detail: id, EMPTY, Duration.ofSeconds(30)); return null; }更徹底的做法是前置布隆過(guò)濾器把存在的ID放在過(guò)濾器里請(qǐng)求先過(guò)過(guò)濾器不在直接返回。布隆過(guò)濾器有誤判率參數(shù)一般設(shè)1%以內(nèi)就夠用。它的缺點(diǎn)是維護(hù)成本高新增商品要同步更新位圖適合ID范圍穩(wěn)定的場(chǎng)景。緩存擊穿是熱點(diǎn)key剛好過(guò)期大量請(qǐng)求同時(shí)打進(jìn)來(lái)。穿透是查不存在的數(shù)據(jù)擊穿是查存在但緩存剛好失效的數(shù)據(jù)。擊穿的標(biāo)準(zhǔn)解法是互斥鎖只有搶到鎖的線程回源其余線程短暫等待后重查緩存。我常用SET key value NX EX做輕量鎖比Redisson更輕適合單機(jī)壓測(cè)練手String lockKey lock:product:detail: id; Boolean ok stringRedisTemplate.opsForValue() .setIfAbsent(lockKey, 1, Duration.ofSeconds(5)); if (Boolean.TRUE.equals(ok)) { try { Product product loadFromDb(id); stringRedisTemplate.opsForValue().set(cacheKey, json, Duration.ofMinutes(30)); } finally { stringRedisTemplate.delete(lockKey); } } else { // 沒(méi)搶到鎖的線程等50ms后重查緩存 Thread.sleep(50); return getProduct(id); }這個(gè)是遞歸重查緩存剛被重建第二次查詢就能命中。注意Thread.sleep時(shí)間不要超過(guò)鎖的過(guò)期時(shí)間否則緩存還沒(méi)建好鎖就沒(méi)了后續(xù)請(qǐng)求還是會(huì)回源。緩存雪崩比擊穿更廣是大批量key同時(shí)過(guò)期或Redis節(jié)點(diǎn)宕機(jī)。解決思路分散化TTL加隨機(jī)偏移應(yīng)對(duì)批量過(guò)期主從哨兵應(yīng)對(duì)單點(diǎn)故障服務(wù)端做多級(jí)緩存兜底本地進(jìn)程內(nèi)緩存扛第一波Redis扛第二波數(shù)據(jù)庫(kù)只接收穿透下來(lái)的請(qǐng)求。3.3 緩存與數(shù)據(jù)庫(kù)一致性先更新庫(kù)還是先刪緩存緩存項(xiàng)目繞不開(kāi)一致性。常見(jiàn)做法是Cache Aside旁路緩存讀的時(shí)候先讀緩存未命中回源數(shù)據(jù)庫(kù)再寫(xiě)緩存寫(xiě)的時(shí)候先更新數(shù)據(jù)庫(kù)再刪除緩存。刪除緩存而不是更新緩存原因有兩個(gè)。第一更新緩存意味著每次寫(xiě)請(qǐng)求都要寫(xiě)Redis如果數(shù)據(jù)庫(kù)更新頻率高緩存會(huì)被頻繁重寫(xiě)白白浪費(fèi)性能。第二并發(fā)更新同一個(gè)key后寫(xiě)的值可能覆蓋先寫(xiě)的緩存里存的東西和數(shù)據(jù)庫(kù)不一致。刪除緩存則讓下次讀請(qǐng)求自然回源重建收斂到正確值。那為什么不是先刪緩存再更新數(shù)據(jù)庫(kù)因?yàn)閮蓚€(gè)操作之間有一個(gè)時(shí)間窗口。線程A先刪緩存線程B讀到緩存為空回源剛好數(shù)據(jù)庫(kù)還是舊值把舊值寫(xiě)回緩存之后線程A才把新值更新到數(shù)據(jù)庫(kù)緩存就永久是臟的了。先更新數(shù)據(jù)庫(kù)再刪緩存雖然刪緩存前有一小段時(shí)間緩存是舊值但最終會(huì)被一次刪除糾正收斂速度快得多。這個(gè)方案并非完全沒(méi)有坑。如果刪除緩存失敗比如Redis命令超時(shí)緩存里還是舊值。線上通用做法是延遲雙刪更新數(shù)據(jù)庫(kù)后刪除緩存隔幾百毫秒再刪一次即使第一次刪除失敗還有第二次兜底。實(shí)際項(xiàng)目里我更建議把刪除緩存動(dòng)作做成可靠消息或本地任務(wù)表異步重試幾次。對(duì)一致性要求極高的賬務(wù)類數(shù)據(jù)不要走緩存直接走數(shù)據(jù)庫(kù)強(qiáng)一致緩存只服務(wù)讀多寫(xiě)少的數(shù)據(jù)。4. 用壓測(cè)把高并發(fā)緩存項(xiàng)目跑穿JMeter、Redis監(jiān)控與集群選型寫(xiě)代碼誰(shuí)都會(huì)但高并發(fā)項(xiàng)目跑不跑得住必須壓測(cè)說(shuō)了算。壓測(cè)不是簡(jiǎn)單開(kāi)幾個(gè)線程打一打要看緩存命中率、TPS拐點(diǎn)和慢日志變化。這一章講我把單機(jī)緩存項(xiàng)目驗(yàn)證到能上線的三板斧。4.1 用JMeter打高并發(fā)壓測(cè)線程組、聚合報(bào)告與三個(gè)必調(diào)參數(shù)JMeter是壓測(cè)高并發(fā)緩存項(xiàng)目的標(biāo)準(zhǔn)工具。常見(jiàn)做法是先用GUI把測(cè)試計(jì)劃配好再命令行跑回歸。線程組是最核心的組件參數(shù)直接影響壓測(cè)結(jié)果參數(shù)建議值作用線程數(shù)200到1000模擬并發(fā)用戶數(shù)Ramp-up30到60秒讓壓力緩慢爬升不要瞬間壓垮循環(huán)次數(shù)100到500保證每個(gè)線程有足夠請(qǐng)求量壓測(cè)需要把Redis緩存先預(yù)熱還是先清空看目標(biāo)而定。測(cè)緩存穿透我用redis-cli把相關(guān)key清空再打測(cè)綜合性能先灌一批熱點(diǎn)數(shù)據(jù)再打。JMeter加HTTP請(qǐng)求采樣器配置里把連接超時(shí)設(shè)為1000ms、響應(yīng)超時(shí)設(shè)為3000ms超過(guò)就當(dāng)成失敗這樣能暴露Redis慢命令的問(wèn)題。命令行跑壓測(cè)是上線前的固定動(dòng)作jmeter -n -t high-concurrency.jmx -l result.jtl -e -o report/跑完后重點(diǎn)看聚合報(bào)告里的三個(gè)數(shù)字吞吐量、90%響應(yīng)時(shí)間和異常率。吞吐量就是每秒能處理多少請(qǐng)求90%響應(yīng)時(shí)間反映用戶體驗(yàn)異常率超過(guò)0.1%就必須查日志。第一次壓測(cè)我一般只開(kāi)200并發(fā)觀察數(shù)據(jù)庫(kù)連接池和Redis內(nèi)存變化再逐步加到500、1000找到TPS拐點(diǎn)。4.2 Redis慢日志與INFO命令壓測(cè)時(shí)的三個(gè)監(jiān)控手段壓測(cè)過(guò)程中不能只盯著JMeterRedis側(cè)的監(jiān)控才決定瓶頸分析方向。我會(huì)同時(shí)開(kāi)三個(gè)終端分別跑慢日志、INFO統(tǒng)計(jì)和bigkeys掃描# 查看最近10條慢日志 redis-cli -h 127.0.0.1 -p 6379 -a $REDIS_PWD slowlog get 10 # 緩存命中率核心指標(biāo) redis-cli info stats | grep -E keyspace_hits|keyspace_misses # 各命令調(diào)用次數(shù)統(tǒng)計(jì)找出熱點(diǎn)命令 redis-cli info commandstats | head -30慢日志默認(rèn)閾值是10000微秒也就是10毫秒。壓測(cè)時(shí)如果發(fā)現(xiàn)大量命令超過(guò)這個(gè)閾值說(shuō)明Redis執(zhí)行被阻塞或key太大。INFO命令里keyspace_hits和keyspace_misses是緩存治理最核心的兩個(gè)數(shù)字命中率公式是hits除以hits加misses。線上運(yùn)營(yíng)正常時(shí)命中率低于80%就要警惕壓測(cè)時(shí)如果命中率驟降多半是緩存預(yù)熱不夠或者TTL設(shè)置不合理。--bigkeys掃描可以找出大key。一個(gè)value超過(guò)1MB的key在高并發(fā)下會(huì)成為熱點(diǎn)瓶頸讀寫(xiě)都慢。壓測(cè)前先跑一遍這個(gè)命令把大key拆掉或換數(shù)據(jù)結(jié)構(gòu)不然壓到一半Redis卡死會(huì)以為是代碼問(wèn)題。4.3 從單機(jī)到集群主從、哨兵和Cluster的邊界單機(jī)壓測(cè)通過(guò)后下一個(gè)問(wèn)題是走到哪一步要開(kāi)始上集群。常見(jiàn)做法分三檔。主從復(fù)制解決的是讀壓力。一臺(tái)master掛多臺(tái)slave讀流量分配到slavemaster只處理寫(xiě)。主從同步是異步的slave上可能有短暫數(shù)據(jù)延遲對(duì)一致性敏感的頁(yè)面不要走slave。哨兵模式解決的是高可用。master掛了哨兵自動(dòng)把slave提升為master應(yīng)用端通過(guò)哨兵感知新的master地址。但一臺(tái)master依然有內(nèi)存上限數(shù)據(jù)量超過(guò)單機(jī)內(nèi)存還是撐不住。Cluster模式解決的是容量和寫(xiě)擴(kuò)展。數(shù)據(jù)按slot均勻分布到多臺(tái)節(jié)點(diǎn)寫(xiě)入可以水平擴(kuò)展。Cluster的代價(jià)是客戶端復(fù)雜度高多key操作要確認(rèn)它們?cè)谕粋€(gè)slot事務(wù)能力也受限。我見(jiàn)過(guò)不少團(tuán)隊(duì)在數(shù)據(jù)量不到5GB時(shí)就上了Cluster運(yùn)維把slot遷移和reshard折騰得苦不堪言。我的建議是先壓測(cè)如果單機(jī)8GB內(nèi)存和哨兵模式能扛住未來(lái)一年的峰值就不要上Cluster。鎖和數(shù)據(jù)一致性復(fù)雜度不值得為不存在的高并發(fā)買(mǎi)單。5. 高并發(fā)緩存項(xiàng)目最容易翻車(chē)的5個(gè)坑現(xiàn)象、原因與解決高并發(fā)緩存項(xiàng)目做完壓測(cè)和上線過(guò)程會(huì)暴露一堆只靠讀文檔發(fā)現(xiàn)不了的問(wèn)題。下面這5條是我反復(fù)踩過(guò)、也幫別人排查過(guò)最多的坑每一條都按現(xiàn)象、原因、解決的順序拆開(kāi)講你可以直接對(duì)照自己的項(xiàng)目。5.1 并發(fā)一高數(shù)據(jù)庫(kù)連接池就報(bào)錯(cuò)緩存形同虛設(shè)現(xiàn)象壓測(cè)線程從200加到500時(shí)數(shù)據(jù)庫(kù)連接池開(kāi)始拋Connection is not available, request timed out但Redis的CPU和內(nèi)存都正常。原因查了下緩存的命中率發(fā)現(xiàn)大量請(qǐng)求在查一個(gè)不存在的ID比如商品ID為負(fù)數(shù)或者已被下架的數(shù)據(jù)。這些key緩存里沒(méi)有回源邏輯每次都查數(shù)據(jù)庫(kù)緩存完全沒(méi)有兜住。這是典型的緩存穿透惡意請(qǐng)求拿不存在的ID反復(fù)打接口時(shí)尤其嚴(yán)重。解決給查詢結(jié)果為空的情況寫(xiě)臨時(shí)緩存TTL設(shè)30秒同時(shí)在前置接口做參數(shù)校驗(yàn)負(fù)數(shù)ID直接返回異常。更穩(wěn)妥的方案是在緩存層加布隆過(guò)濾器ID不在集合里的請(qǐng)求直接丟棄不用碰數(shù)據(jù)庫(kù)。5.2 分布式鎖搶到了還是超賣(mài)庫(kù)存扣成負(fù)數(shù)現(xiàn)象壓測(cè)秒殺接口時(shí)庫(kù)存總數(shù)1000件實(shí)際賣(mài)出去1200件日志里每個(gè)線程都聲稱自己搶到了鎖。原因鎖沒(méi)搶到不等同于業(yè)務(wù)沒(méi)執(zhí)行。我把鎖的tryLock返回值當(dāng)成成功標(biāo)志但沒(méi)在失敗時(shí)終止流程線程繼續(xù)往下執(zhí)行扣庫(kù)存。另外一個(gè)更隱蔽的原因是鎖value寫(xiě)死了固定字符串線程A釋放鎖時(shí)把線程B的鎖也刪了。兩個(gè)線程同時(shí)持鎖超賣(mài)就必然發(fā)生。解決tryLock返回false必須直接拋異?；蚍祷亍皳屬?gòu)失敗”不能繼續(xù)往下走。釋放鎖改用Lua腳本比對(duì)value再刪除確保只能刪自己的鎖。用Redisson的話配置watchdog自動(dòng)續(xù)期避免業(yè)務(wù)執(zhí)行超過(guò)鎖租約時(shí)間。5.3 同期設(shè)置的緩存key在同一秒失效緩存命中率一夜回到解放前現(xiàn)象零點(diǎn)過(guò)后緩存命中率從95%暴跌到40%數(shù)據(jù)庫(kù)壓力暴漲持續(xù)一兩分鐘后才恢復(fù)?？碦edis慢日志大批KEYS命令和同前綴的GET命令同時(shí)出現(xiàn)。原因所有商品詳情key都是寫(xiě)入時(shí)固定加30分鐘TTL同一批商品在同一時(shí)間失效形成批量緩存雪崩。雖然Redis還活著但數(shù)據(jù)庫(kù)被回源流量打蒙了接口響應(yīng)時(shí)間翻了十倍。解決TTL不再寫(xiě)死寫(xiě)入時(shí)加隨機(jī)偏移讓過(guò)期時(shí)間分散在前后一分鐘內(nèi)。同時(shí)給熱點(diǎn)商品加一個(gè)主動(dòng)續(xù)期邏輯訪問(wèn)時(shí)如果TTL低于閾值就把TTL續(xù)到30分鐘相當(dāng)于給熱點(diǎn)數(shù)據(jù)續(xù)命。5.4 Redis可視化工具里全是亂碼value長(zhǎng)這樣\xAC\xED\x00\x05t現(xiàn)象用Redis Desktop Manager打開(kāi)緩存實(shí)例key顯示成\xAC\xED\x00\x05tProductvalue也是\xAC\xED\x00\x05開(kāi)頭的一串亂碼命令行里卻能看到業(yè)務(wù)字符串。原因RedisTemplate默認(rèn)使用JdkSerializationRedisSerializerJava對(duì)象先被JDK序列化成二進(jìn)制再存進(jìn)Redis。JDK序列化后的數(shù)據(jù)帶類型簽名可讀性極差還會(huì)在value里附帶類路徑占空間。這不是Redis的問(wèn)題是客戶端序列化方式選錯(cuò)了。解決統(tǒng)一改用StringRedisTemplatekey和value都存字符串。對(duì)象先轉(zhuǎn)JSON字符串再寫(xiě)入讀取時(shí)再反序列化。如果必須用RedisTemplate把valueSerializer替換成GenericJackson2JsonRedisSerializerkey保持StringRedisSerializer。改完后可視化工具和命令行看到的內(nèi)容都應(yīng)該是可讀JSON。5.5 Redis command timed outLettuce連接池被打滿現(xiàn)象高并發(fā)壓測(cè)時(shí)應(yīng)用日志頻繁報(bào)Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException幾分鐘后接口大面積超時(shí)。原因Lettuce作為Spring Boot默認(rèn)客戶端是異步的但如果connection pool配置不對(duì)它會(huì)把請(qǐng)求阻塞在等待連接上。我遇到過(guò)把max-idle設(shè)成8、max-active設(shè)成16的小池子壓到200并發(fā)時(shí)所有連接都被占滿新請(qǐng)求全部超時(shí)。另外一個(gè)原因是Redis側(cè)有慢命令比如處理很大的Hash單個(gè)命令耗時(shí)超過(guò)客戶端的timeout閾值。解決先把max-active調(diào)到壓測(cè)并發(fā)數(shù)以上的值比如500并發(fā)配80個(gè)連接max-wait設(shè)300到500毫秒。然后查Redis慢日志找到耗時(shí)超過(guò)客戶端timeout的命令拆大key或換數(shù)據(jù)結(jié)構(gòu)。如果業(yè)務(wù)對(duì)單點(diǎn)延遲敏感客戶端timeout和Redis慢日志閾值要同步調(diào)讓超時(shí)先于隊(duì)列堆積出現(xiàn)便于提前發(fā)現(xiàn)瓶頸。6. 緩存Key命名與上線前的自查習(xí)慣高并發(fā)緩存項(xiàng)目收尾時(shí)我堅(jiān)持做三件事key命名統(tǒng)一、TTL隨機(jī)化、上線前壓測(cè)。key命名我最常用的是“業(yè)務(wù):場(chǎng)景:ID:版本”格式比如mall:product:detail:1001:v2。業(yè)務(wù)前綴方便按產(chǎn)品線隔離場(chǎng)景前綴方便定位用途ID是具體數(shù)據(jù)版本號(hào)是給緩存結(jié)構(gòu)升級(jí)留的后路。用冒號(hào)而不是下劃線因?yàn)镽edis Desktop Manager和另一個(gè)可視化工具會(huì)把冒號(hào)自動(dòng)折疊成目錄樹(shù)排查效率高很多。上線前我有個(gè)固定checklist抽查高流量緩存key是不是都帶了隨機(jī)TTL偏移用redis-cli --bigkeys確認(rèn)沒(méi)有超過(guò)1MB的大key跑一次200并發(fā)的壓測(cè)看緩存命中率和慢日志有沒(méi)有異常確認(rèn)Redis可視化工具里能看到正常JSON而不是JDK序列化的亂碼。這套動(dòng)作看起來(lái)瑣碎但每次都能攔住至少一個(gè)上線事故。我的個(gè)人習(xí)慣是把線上緩存問(wèn)題當(dāng)成黑匣子來(lái)記錄什么時(shí)間點(diǎn)命中率下降、當(dāng)時(shí)連著做了多少次回源、Redis慢日志里是哪類命令記多了會(huì)發(fā)現(xiàn)大多數(shù)緩存事故的根源就那幾個(gè)。高并發(fā)緩存項(xiàng)目最大的價(jià)值不是把Redis用熟而是學(xué)會(huì)在數(shù)據(jù)庫(kù)被打爆之前靠監(jiān)控?cái)?shù)據(jù)把痛點(diǎn)定位出來(lái)。希望這些參數(shù)和踩坑記錄能幫你少走一段彎路希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取