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