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