Redis深度實踐：從緩存配置到分布式鎖與集群部署)
如果你問我后臺管理系統(tǒng)里最容易被低估的中間件是什么我會說Redis。很多團隊把Redis當成一個“放Token的緩存庫”就完事了但實際上在eladmin這種基于Spring Boot的后臺管理系統(tǒng)里Redis能承擔的角色遠比你想象得多。從用戶登錄態(tài)、驗證碼、在線用戶到字典緩存、分布式鎖、接口限流計數(shù)器再到集群部署后的Session協(xié)調它幾乎參與了業(yè)務鏈路的每一層。我最早接手團隊eladmin項目時Redis已經配好了但一查監(jiān)控全是問題——key亂碼、緩存不生效、分布式鎖偶爾失效、主從切換后計數(shù)器歸零。這篇文章我把這幾輪踩坑和重構的過程完整寫出來包含配置、序列化、緩存注解、分布式鎖、故障處理和部署升級路線適合正在用或準備用eladmin做二次開發(fā)的朋友參考。先說個結論eladmin本身自帶一套緩存機制很多基礎代碼里也預留了Redis的入口但默認狀態(tài)下的使用深度遠遠不夠。如果你只是把它當成“驗證碼臨時存儲”那你既沒發(fā)揮Redis的價值也遲早會在高并發(fā)或集群場景下栽跟頭。接下來我按實際項目推進的順序來講。1. eladmin為什么需要Redis從登錄態(tài)到緩存的架構動因1.1 eladmin原生架構下的存儲瓶頸eladmin的默認設計里用戶認證走的是JWT也就是服務端簽發(fā)一個Token前端每次請求都帶上后端通過攔截器解析鑒權。好處是服務端無狀態(tài)但問題也很明顯Token一旦簽發(fā)服務端沒法主動讓它失效。你改了用戶權限、禁用了賬號、踢了下線只要Token沒到期用戶依然能訪問接口。這是我在實際項目里最痛苦的體驗之一。解決思路很簡單把Token的狀態(tài)存到Redis里。用戶登錄后生成一個會話KeyJWT信息、用戶基本信息、權限快照都放進去鑒權時先查Redis里的“會話是否還在”。這樣賬號禁用、權限變動、強制下線都能實時生效。eladmin的登錄邏輯本身是基于在線用戶管理的如果配合Redis做會話存儲整個認證鏈路的可控性會提升一個檔次。1.2 Redis在eladmin里的四種典型角色我把Redis在一個成熟eladmin項目里承擔的工作分成四類緩存層字典數(shù)據(jù)、部門樹、角色權限、菜單、系統(tǒng)配置項這類讀多寫少的數(shù)據(jù)全部放進Redis降低數(shù)據(jù)庫壓力。會話與臨時數(shù)據(jù)登錄Token、驗證碼、短信驗證碼、文件上傳分片信息、導入導出的臨時文件索引。分布式協(xié)調定時任務防重執(zhí)行、庫存扣減、操作冪等、分布式鎖。計數(shù)器與限流登錄失敗次數(shù)統(tǒng)計、短信發(fā)送頻率控制、接口調用頻控依賴Redis的原子自增操作。這四類場景在eladmin里幾乎都能找到對應的業(yè)務入口。你會發(fā)現(xiàn)Redis在后臺系統(tǒng)里不是“可選項”而是“基礎設施”。1.3 引入Redis前后的一次對比我團隊當時做了一個很小的壓測同樣的字典查詢接口數(shù)據(jù)庫直連查詢平均12ms命中Redis緩存之后平均0.8msQPS從900左右升到接近7000。這個差距在單機環(huán)境不明顯但一旦上了集群、數(shù)據(jù)量上來緩存層的存在就是生死線。而且Redis本身是單線程模型IO多路復用性能非常穩(wěn)定配合Spring Boot Cache抽象層幾乎不用在業(yè)務代碼里寫很重的緩存邏輯。提示eladmin的依賴里其實已經引入了spring-boot-starter-data-redis但很多分支版本沒有把序列化器配好。第一步不是寫業(yè)務而是把RedisTemplate的序列化配置修正否則后面全是亂碼和ClassCastException。2. RedisTemplate序列化配置接入eladmin的第一個分水嶺2.1 默認JDK序列化帶來的亂碼問題我見過太多eladmin項目Redis里長這樣一堆以\xAC\xED\x00\x05t...開頭的keyvalue用Redis Desktop Manager打開全是亂碼。這是因為Spring Boot默認的RedisTemplate用的是JdkSerializationRedisSerializer它會把對象序列化成二進制字節(jié)不僅肉眼不可讀還會因為類結構變化導致反序列化失敗。另外JDK序列化會附帶大量類元信息一條簡單的用戶緩存可能膨脹到幾KB內存浪費嚴重。這在開發(fā)階段還能忍上了生產就是事故。比如你發(fā)版時改了實體類的字段舊緩存的二進制流反序列化直接拋異常緩存層級崩潰數(shù)據(jù)庫瞬間被打爆。2.2 用GenericJackson2JsonRedisSerializer做全局序列化eladmin的RedisConfig應該重寫兩個BeanRedisTemplate和StringRedisTemplate。核心思路是key序列化用StringRedisSerializer保證可讀性。value序列化用GenericJackson2JsonRedisSerializer把對象轉成JSON字符串存儲兼容性好且能通過class字段保存類型信息反序列化時不丟類型。hash的key和value也分別指定序列化器。一個我實際在用的配置如下Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // key 使用 String 序列化 StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }這里有個細節(jié)GenericJackson2JsonRedisSerializer默認會把類型信息寫在JSON的class字段里。如果你緩存的對象里有接口類型、父類引用或者泛型反序列化時這一手非常關鍵。但它也不是萬能的遇到LocalDateTime這類Java 8時間類型時容易出問題一個常見的坑是序列化后變成數(shù)組格式。我在eladmin里處理這種場景時會在ObjectMapper里注冊JavaTimeModule并調整日期序列化的格式避免前后端解析不一致。2.3 緩存key的設計規(guī)范序列化只是第一步key的命名同樣重要。Redis是鍵值存儲沒有表結構約束key設計是否規(guī)范直接決定后續(xù)運維的體驗。我在eladmin里定的規(guī)范是業(yè)務域:模塊:唯一標識例如auth:token:{userId}用戶會話sys:dict:{dictName}字典緩存sys:dept:tree部門樹緩存lock:task:{taskName}定時任務的分布式鎖這樣用Redis Desktop Manager或者命令行SCAN匹配前綴時非常清晰也能通過命名空間做批量清理。另外key盡量短一些能用ID就不拼長字符串節(jié)省內存也提高查詢效率。2.4 配置完成后的最小驗證配置改完后不要急著寫業(yè)務先做一個最小驗證SpringBootTest public class RedisTest { Resource private RedisTemplateString, Object redisTemplate; Test public void test() { redisTemplate.opsForValue().set(auth:token:1, hello-redis); Object value redisTemplate.opsForValue().get(auth:token:1); System.out.println(value); } }跑通這一步再去Redis客戶端看key是否可讀、value是不是JSON字符串。如果看到類似hello-redis的文本內容就說明序列化配置生效了。提示不要用RedisTemplate直接存泛型對象比如ListUser如果JSON里只存了class到List內部元素類型容易丟失。穩(wěn)妥做法是自定義一個帶類型包裝的DTO或者用redisTemplate.opsForValue().set(key, JSON.toJSONString(list))配合反序列化手動指定類型。3. 緩存注解和RedisUtils兩種緩存方式的邊界3.1 Cacheable適合哪些業(yè)務eladmin里大量使用Spring Cache的注解緩存比如Cacheable、CacheEvict。注解方式的好處是侵入性小業(yè)務代碼里不用手寫存取邏輯。適合以下幾類字典類型列表按類型名緩存。部門樹、菜單樹按用戶ID緩存。系統(tǒng)配置項按配置鍵緩存。角色權限集合按角色ID緩存。一個典型例子Cacheable(value sys:dict, key #type, unless #result null) public ListDictDetail getDictDetails(String type) { // 數(shù)據(jù)庫查詢 }這樣第一次查詢后結果進入Redis后續(xù)請求直接命中緩存。但注解緩存有幾個隱藏問題我后面還會講失效時間不好精細控制、緩存擊穿場景下注解幫不上忙、更新時機容易亂。3.2 eladmin里的RedisUtils手動緩存eladmin原生的RedisUtils工具類是非常實用的封裝它把常用的set、get、delete、exists、expire都包了一遍并在設置值時自動指定過期時間。對于簡單的數(shù)據(jù)我建議直接用這個工具類而不是每個地方都寫redisTemplate.opsForValue().xxx()。手動緩存適合以下場景數(shù)據(jù)短生命周期比如登錄驗證碼5分鐘有效。需要精細控制過期時間。緩存數(shù)據(jù)需要在業(yè)務中頻繁更新比如在線用戶狀態(tài)。數(shù)據(jù)緩存與數(shù)據(jù)庫更新之間需要手動維護一致性注解方式很難表達“先改庫再刪緩存”的順序。舉個eladmin里的實際例子登錄成功之后把用戶信息塞進Redis設置30分鐘過期每次請求時刷新過期時間實現(xiàn)“滑動續(xù)期”。這個需求用Cacheable做不到因為注解緩存不支持動態(tài)刷新TTL但RedisUtils可以輕松完成。3.3 緩存更新機制優(yōu)先刪而不是更新這是我吃了虧才明白的道理。很多人寫完緩存后想當然地認為數(shù)據(jù)庫更新后把Redis值也更新就好了。但緩存更新的路數(shù)很多組合方式容易出錯。比如先更新數(shù)據(jù)庫還是先更新緩存、失敗了怎么辦、并發(fā)下會不會讀到舊值。eladmin業(yè)務里我統(tǒng)一采用“先更新數(shù)據(jù)庫再刪除緩存”的策略。下一請求發(fā)現(xiàn)緩存未命中再回源數(shù)據(jù)庫重建緩存。這個策略在大多數(shù)讀多寫少的后臺系統(tǒng)里足夠用而且天然避免了“寫緩存失敗導致數(shù)據(jù)不一致”的問題。刪除緩存這個動作本身也是冪等的就算刪晚了也只是多一次數(shù)據(jù)庫查詢。3.4 字典緩存的完整案例以eladmin的字典模塊為例它的查詢頻率很高但字典數(shù)據(jù)基本穩(wěn)定。如果每次查字典都走數(shù)據(jù)庫查詢接口響應會受DB性能影響。我的處理方式啟動時預熱項目啟動后調用一次字典查詢接口把常用字典寫進Redis。查詢時先查緩存命中直接返回。后臺編輯字典后調用刪除緩存接口保證下次查詢回源。這里有一個細節(jié)分頁查詢的字典列表不適合直接整體緩存因為分頁排序條件太多緩存命中率低還會造成緩存key爆炸。我只對“按字典名稱查詢所有明細”這種固定場景做緩存列表頁不緩存Excel導出也不緩存。緩存不是越多越好命中率低的緩存不僅浪費內存還增加了維護成本。4. 分布式鎖從緩存組件到協(xié)調組件4.1 為什么單機鎖不夠eladmin里的定時任務、庫存扣減類操作在單機部署時用Synchronized或ReentrantLock沒問題。但項目上了集群同樣的定時任務會在每個節(jié)點各執(zhí)行一遍造成重復數(shù)據(jù)。比如定時同步訂單狀態(tài)如果兩臺機器同時跑數(shù)據(jù)庫可能被更新兩次產生臟數(shù)據(jù)。單機鎖只對本進程生效這時就需要一個跨進程的鎖分布式鎖。Redis實現(xiàn)分布式鎖是最常見的方案因為它本身是共享存儲所有節(jié)點都能訪問且提供了原子操作。4.2 用Redis手寫一個可用的分布式鎖最簡單可靠的方案就是基于SET key value NX EX seconds這個命令能同時保證“key不存在才設置”和“過期時間自動設置”。用RedisTemplate實現(xiàn)如下public boolean tryLock(String key, String requestId, long expireSeconds) { // NX: 不存在才設置 EX: 設置過期時間 // 注意 SET_IF_ABSENT NX, SET_ABSENT_TIME EX Boolean result redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); return Boolean.TRUE.equals(result); } public boolean releaseLock(String key, String requestId) { // 使用Lua腳本保證“校驗持有者再刪除”是原子操作 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, List.of(key), requestId); return Long.valueOf(1).equals(result); }這里有兩個關鍵點requestId可以是UUID是鎖持有者的唯一標識。釋放鎖時必須校驗這個標識防止“自己不持有的鎖被自己刪掉”。用Lua腳本包裹“檢查-刪除”操作保證原子性。如果拆成兩步可能在GET之后、DEL之前鎖到期被另一個線程搶走然后你把別人的鎖刪了。4.3 鎖的續(xù)期問題和Redisson選擇手寫鎖有個麻煩業(yè)務執(zhí)行時間超過鎖的過期時間怎么辦比如加鎖時設了30秒但業(yè)務跑了40秒鎖自動釋放另一個線程進來了。解決思路是續(xù)期——在鎖即將到期但業(yè)務還沒結束時自動延長過期時間。這個邏輯很煩不建議手寫。我在這塊直接引入了Redisson它內置了看門狗機制默認鎖續(xù)期到30秒每10秒檢查一次業(yè)務沒結束就自動續(xù)期業(yè)務結束就釋放鎖。代碼反而簡單很多RLock lock redissonClient.getLock(lock:task:syncOrder); boolean isLocked lock.tryLock(3, 10, TimeUnit.SECONDS); if (isLocked) { try { // 業(yè)務邏輯 } finally { lock.unlock(); } }引入Redisson的代價是加一個依賴和一點內存但省去了自己處理續(xù)期、重入、異常釋放的雜活。eladmin里如果已經有Redisson依賴優(yōu)先用它的tryLock如果沒有手寫一個簡單的也夠用。提示手寫鎖務必設置過期時間絕不能只用setIfAbsent(key, value)不帶過期時間。一旦分布式鎖的key沒有過期時間而持有鎖的服務宕機這個鎖就永遠解不開了下游業(yè)務全部卡死。4.4 鎖定在eladmin里的實際場景我在eladmin里落地分布式鎖最多的場景是定時任務。eladmin有定時任務管理模塊可以動態(tài)啟停任務但任務本身可能被多個節(jié)點同時觸發(fā)。處理方式任務執(zhí)行入口先嘗試獲取鎖。搶到鎖的節(jié)點執(zhí)行任務沒搶到的節(jié)點直接跳過。執(zhí)行完成后主動釋放鎖。另外批量導入導出、文件分片合并、訂單狀態(tài)機轉換這類場景也需要鎖。核心思路是凡是“多實例下同一時間只允許一個執(zhí)行”的操作都值得用分布式鎖。5. 緩存三大故障現(xiàn)場穿透、擊穿、雪崩的解決實錄5.1 緩存穿透不存在的key瘋狂打庫eladmin里權限校驗接口如果被惡意刷每次都會攜帶一個不存在的用戶ID查數(shù)據(jù)庫Redis里始終沒有緩存數(shù)據(jù)庫壓力直線上升。這種查詢一個“必然不存在的數(shù)據(jù)”的現(xiàn)象就是緩存穿透。最常用的兩個辦法緩存空值查詢結果為空也寫緩存設置一個較短的過期時間比如60秒這樣后續(xù)相同Key不會打到DB。但要注意空值過多會占用內存需要設置過期時間。布隆過濾器把所有合法的用戶ID加載到布隆過濾器查詢前先判斷ID是否存在不存在直接返回。適用于ID集合較小且相對固定的場景。我在eladmin里處理驗證碼校驗接口時用的就是緩存空值方案驗證碼錯誤就緩存一個錯誤標記過期時間比驗證碼本身還短。這樣既保護了數(shù)據(jù)庫又不會影響正常用戶的重新發(fā)送。5.2 緩存擊穿熱點key瞬間過期打崩DB緩存擊穿和穿透容易混淆擊穿指的是某個熱點key在過期瞬間大量并發(fā)請求同時回源數(shù)據(jù)庫。比如eladmin的系統(tǒng)配置緩存如果剛好在零點過期所有請求都去查數(shù)據(jù)庫一次就夠數(shù)據(jù)庫喝一壺。解決手段通常有兩種互斥重建用分布式鎖包住回源邏輯只允許一個線程回源數(shù)據(jù)庫寫緩存其他線程等待緩存重建完成。缺點是鎖等待會增加接口耗時。邏輯過期緩存中不設置物理過期時間而是存一個邏輯過期戳。查詢時發(fā)現(xiàn)戳已經過期就異步重建。優(yōu)點是接口永遠有數(shù)據(jù)可返回但實現(xiàn)稍復雜。在eladmin的字典緩存里我采用的是折中方案熱點key的物理過期時間拉長到小時級后端修改字典后通過ActiveMQ或者直接調用刪除緩存接口來維護一致性避免“自然過期”引發(fā)擊穿。這個方案簡單但依賴“刪除操作必須可靠”。5.3 緩存雪崩大量key同一時刻失效雪崩和擊穿的區(qū)別在于影響范圍。雪崩是大批key在同一時間過期或者Redis服務整體不可用導致數(shù)據(jù)庫瞬間被沖垮。解決辦法我總結三條過期時間加隨機抖動比如基礎過期時間300秒實際設置時加一個0到60秒的隨機數(shù)避免同一秒集體失效。eladmin里的緩存工具類我已經統(tǒng)一封裝了這個邏輯。多級緩存配合Redis之上加一層本地緩存Caffeine本地緩存失效再查RedisRedis失效再查DB。這樣即使Redis短時間不可用本地緩存還能扛一部分。Redis高可用部署主從加哨兵或者Redis Cluster避免單點故障。這個我放在第6節(jié)詳細講。5.4 曾經踩過的坑INCR在分布式環(huán)境下的“不準”熱詞里有一條“redis incr不準”我在eladmin里也遇到過。場景是短信驗證碼發(fā)送頻率限制Long count redisTemplate.opsForValue().increment(limit:sms: phone); redisTemplate.expire(limit:sms: phone, 60, TimeUnit.SECONDS);這段代碼在單機Redis下沒有問題。但在主從架構下主機自增后同步給從機如果主機宕機、從機頂上自增的值可能丟失或重復導致計數(shù)不準。解決方案有幾個使用Redis Cluster的單一分片鎖住key的哈希槽保證只有一臺機器處理該key。頻率限制場景可以接受誤差時改成SETNX 過期時間判斷邏輯?；蛘咴赗edis事務Pipeline中執(zhí)行減少錯誤概率。另外INCR和EXPIRE是兩個獨立命令如果想讓key自動過期最好用Lua腳本把兩個操作包起來保證原子性否則極端情況下可能key永不過期計數(shù)累加超過預期。提示eladmin的接口限流功能如果用了IP計數(shù)千萬不要用get再set的復合操作必須用原生INCR。兩步操作在并發(fā)下會丟失增量計數(shù)這是非常隱蔽的一類bug。6. 從單機到集群eladmin上線后的Redis部署升級路線6.1 單機版夠用嗎開發(fā)環(huán)境和日活幾千的小項目單機Redis完全夠用。eladmin這種后臺系統(tǒng)數(shù)據(jù)庫字段多、接口讀寫比例高單臺8G內存的Redis實例支撐幾百個并發(fā)是沒問題的。但是單機的問題在于故障域。Redis宕機所有緩存全部失效數(shù)據(jù)庫被瞬時打滿整個系統(tǒng)雪崩。而且一臺機器上Redis進程如果OOMRedis會直接拒絕寫入進而影響所有依賴Redis的業(yè)務。因此正規(guī)一點的項目都會考慮主從。6.2 主從加哨兵怎么配更穩(wěn)主從模式解決的是“單點故障”哨兵解決的是“自動故障轉移”。我在eladmin生產環(huán)境用的一主二從加三哨兵架構主節(jié)點負責讀寫。從節(jié)點負責讀擴展和備份。哨兵監(jiān)控主從狀態(tài)主節(jié)點宕機后自動從從節(jié)點選舉出一個新主節(jié)點修改客戶端配置的地址指向新主節(jié)點。Spring Boot里配置Sentinel模式的地址很簡單spring: data: redis: sentinel: master: mymaster nodes: - 192.168.1.10:26379 - 192.168.1.11:26379 - 192.168.1.12:26379注意哨兵模式下應用連接的是哨兵地址而不是Redis節(jié)點地址。哨兵會告訴你當前可寫的主節(jié)點是誰。這塊如果配錯應用會一直連不上Redis日志里反復報Connection refused。主從復制還有一個核心點需要注意replica-read-only建議設置為yes。從節(jié)點只做讀寫操作全部走主節(jié)點否則可能會發(fā)生數(shù)據(jù)不一致。6.3 什么時候值得上ClusterRedis Sentinel解決的是“故障轉移”但單節(jié)點的內存容量上限還在。當緩存數(shù)據(jù)量大到單節(jié)點內存裝不下或者寫入并發(fā)超過單實例上限時就該考慮Redis Cluster。Cluster采用分片存儲每個key根據(jù)CRC16算法映射到16384個哈希槽中的某一個然后哈希槽分配給不同節(jié)點。好處是容量和性能都線性擴展壞處是配置復雜、客戶端要支持Cluster模式且Redis Cluster不支持多key操作除非這些key在同一個Hash標簽下。eladmin項目的緩存體量通常到不了Cluster的規(guī)模但如果未來做多租戶、數(shù)據(jù)量暴漲可以提前把key的Hash Tag設計好比如把所有需要一起操作的key都加上{user:1}這樣的Hash前綴確保它們落在同一個槽里。這個設計越早做越省事。6.4 Docker部署Redis時的常見錯誤很多團隊用Docker部署Redis熱詞里提到的“docker search redis request returned 500 internal server error”我碰到過多次。這個報錯通常是Docker Desktop的引擎沒起來或者API版本不兼容解決辦法是重啟Docker Desktop或者檢查Docker引擎的版本。真正進入docker pull redis階段之后還需要注意掛載持久化目錄比如/data防止容器重啟后數(shù)據(jù)丟失。指定Redis密碼和配置文件不要用默認無密碼的配置。如果宿主機和Redis容器不在同一網(wǎng)絡需要注意防火墻和端口映射。用Docker Compose部署一主二從加哨兵集群是本地復現(xiàn)和學習的好方式比手動敲命令省心很多。但這個更多是運維話題本文就不展開了。7. 體檢清單慢查詢、大key和熱點key的排查手段7.1 Redis慢查詢日志怎么看Redis的慢查詢日志和MySQL的slow query log思路類似。配置項slowlog-log-slower-than設置超時閾值單位微秒slowlog-max-len設置日志條數(shù)。執(zhí)行SLOWLOG GET可以查看最近慢查詢命令。eladmin的緩存基本都是小Key很少有長命令但如果有KEYS *這類命令出現(xiàn)在慢查詢里基本可以斷定代碼有問題。Redis是單線程的一個耗時的KEYS命令會阻塞所有客戶端響應線上絕不能執(zhí)行。我見過有人用KEYS auth:token:*來批量清理用戶會話導致Redis卡了幾秒所有依賴緩存的接口全部超時。正確做法是用SCAN游標遍歷分批次刪除。7.2 大key是隱藏的內存炸彈大key通常指value特別大的key比如一個Hash里塞了幾十萬個字段或者一個String存了幾MB的數(shù)據(jù)。大key會導致Redis內存碎片增加、刪除/序列化耗時變長還會在主從復制時造成網(wǎng)絡帶寬壓力。在eladmin里最常見的兩個大key場景緩存的用戶權限集合沒有控制大小一個超管用戶的權限菜單串成一個大JSON。字典緩存把所有數(shù)據(jù)一股腦塞進一個key而不是按類型拆分。排查手段用redis-cli --bigkeys它會掃描找出大key并給出類型和建議。治理方式很直接大key拆小key、續(xù)期策略調整、數(shù)據(jù)結構優(yōu)化。比如權限集合按角色拆分字典按類型拆分。7.3 內存淘汰策略的選擇Redis內存寫滿后怎么辦配置maxmemory-policy決定了淘汰策略。后臺管理系統(tǒng)里我推薦volatile-lru只在設置了過期時間的key里淘汰最近最少使用的數(shù)據(jù)。這樣業(yè)務緩存是“可淘汰”的但正在使用的會話數(shù)據(jù)不會被強制清掉。相比之下allkeys-lru會對所有key做淘汰包括你不想丟的業(yè)務緩存可能導致關鍵數(shù)據(jù)意外消失。還有一點maxmemory不要設成Redis所在服務器的全部內存要留出一部分給操作系統(tǒng)、其他進程防止Redis OOM把整臺服務器壓垮。我一般給Redis分配機器內存的60%-70%左右。7.4 可視化工具和日常巡檢建議命令行工具就是redis-cli圖形化工具我常用Another Redis Desktop Manager和Redis Insight。選工具主要看是否支持連接哨兵、Cluster、SSH隧道。日常巡檢建議做成定時腳本每天掃一遍INFO memory查看內存使用率。INFO replication查看主從復制狀態(tài)確認沒有斷連。INFO stats看連接數(shù)和命中率。SLOWLOG GET 50檢查慢命令。這些指標配合Prometheus和Grafana可以做到很完善的監(jiān)控但哪怕沒有專業(yè)監(jiān)控系統(tǒng)定時敲一下命令也比完全不看強一百倍。Redis掛了不可怕可怕的是你不知道它什么時候開始變慢、內存什么時候開始飆升。結尾經驗這套東西從頭到尾梳理下來我覺得在eladmin里用好Redis的關鍵只有兩點一是序列化和key設計必須在一開始就定好規(guī)范這個決定后續(xù)所有緩存代碼的體驗二是把分布式鎖、緩存擊穿、集群部署這些“進階能力”當作標配去考慮而不是等出了事故再補。我經歷過Redis配置亂碼導致生產環(huán)境接口直接500的夜晚也經歷過分布式鎖誤刪把定時任務數(shù)據(jù)弄亂的尷尬?，F(xiàn)在已經養(yǎng)成的習慣是任何redisTemplate的讀寫都先問自己“key規(guī)范嗎序列化對嗎過期時間設了嗎這行代碼在集群下還成立嗎”這四個問題能擋住絕大部分線上事故。希望這篇實踐對正在折騰eladmin的朋友有幫助。 eladmin后臺系統(tǒng)Redis深度實踐：從緩存配置到分布式鎖與集群部署
如果你問我后臺管理系統(tǒng)里最容易被低估的中間件是什么我會說Redis。很多團隊把Redis當成一個“放Token的緩存庫”就完事了但實際上在eladmin這種基于Spring Boot的后臺管理系統(tǒng)里Redis能承擔的角色遠比你想象得多。從用戶登錄態(tài)、驗證碼、在線用戶到字典緩存、分布式鎖、接口限流計數(shù)器再到集群部署后的Session協(xié)調它幾乎參與了業(yè)務鏈路的每一層。我最早接手團隊eladmin項目時Redis已經配好了但一查監(jiān)控全是問題——key亂碼、緩存不生效、分布式鎖偶爾失效、主從切換后計數(shù)器歸零。這篇文章我把這幾輪踩坑和重構的過程完整寫出來包含配置、序列化、緩存注解、分布式鎖、故障處理和部署升級路線適合正在用或準備用eladmin做二次開發(fā)的朋友參考。先說個結論eladmin本身自帶一套緩存機制很多基礎代碼里也預留了Redis的入口但默認狀態(tài)下的使用深度遠遠不夠。如果你只是把它當成“驗證碼臨時存儲”那你既沒發(fā)揮Redis的價值也遲早會在高并發(fā)或集群場景下栽跟頭。接下來我按實際項目推進的順序來講。1. eladmin為什么需要Redis從登錄態(tài)到緩存的架構動因1.1 eladmin原生架構下的存儲瓶頸eladmin的默認設計里用戶認證走的是JWT也就是服務端簽發(fā)一個Token前端每次請求都帶上后端通過攔截器解析鑒權。好處是服務端無狀態(tài)但問題也很明顯Token一旦簽發(fā)服務端沒法主動讓它失效。你改了用戶權限、禁用了賬號、踢了下線只要Token沒到期用戶依然能訪問接口。這是我在實際項目里最痛苦的體驗之一。解決思路很簡單把Token的狀態(tài)存到Redis里。用戶登錄后生成一個會話KeyJWT信息、用戶基本信息、權限快照都放進去鑒權時先查Redis里的“會話是否還在”。這樣賬號禁用、權限變動、強制下線都能實時生效。eladmin的登錄邏輯本身是基于在線用戶管理的如果配合Redis做會話存儲整個認證鏈路的可控性會提升一個檔次。1.2 Redis在eladmin里的四種典型角色我把Redis在一個成熟eladmin項目里承擔的工作分成四類緩存層字典數(shù)據(jù)、部門樹、角色權限、菜單、系統(tǒng)配置項這類讀多寫少的數(shù)據(jù)全部放進Redis降低數(shù)據(jù)庫壓力。會話與臨時數(shù)據(jù)登錄Token、驗證碼、短信驗證碼、文件上傳分片信息、導入導出的臨時文件索引。分布式協(xié)調定時任務防重執(zhí)行、庫存扣減、操作冪等、分布式鎖。計數(shù)器與限流登錄失敗次數(shù)統(tǒng)計、短信發(fā)送頻率控制、接口調用頻控依賴Redis的原子自增操作。這四類場景在eladmin里幾乎都能找到對應的業(yè)務入口。你會發(fā)現(xiàn)Redis在后臺系統(tǒng)里不是“可選項”而是“基礎設施”。1.3 引入Redis前后的一次對比我團隊當時做了一個很小的壓測同樣的字典查詢接口數(shù)據(jù)庫直連查詢平均12ms命中Redis緩存之后平均0.8msQPS從900左右升到接近7000。這個差距在單機環(huán)境不明顯但一旦上了集群、數(shù)據(jù)量上來緩存層的存在就是生死線。而且Redis本身是單線程模型IO多路復用性能非常穩(wěn)定配合Spring Boot Cache抽象層幾乎不用在業(yè)務代碼里寫很重的緩存邏輯。提示eladmin的依賴里其實已經引入了spring-boot-starter-data-redis但很多分支版本沒有把序列化器配好。第一步不是寫業(yè)務而是把RedisTemplate的序列化配置修正否則后面全是亂碼和ClassCastException。2. RedisTemplate序列化配置接入eladmin的第一個分水嶺2.1 默認JDK序列化帶來的亂碼問題我見過太多eladmin項目Redis里長這樣一堆以\xAC\xED\x00\x05t...開頭的keyvalue用Redis Desktop Manager打開全是亂碼。這是因為Spring Boot默認的RedisTemplate用的是JdkSerializationRedisSerializer它會把對象序列化成二進制字節(jié)不僅肉眼不可讀還會因為類結構變化導致反序列化失敗。另外JDK序列化會附帶大量類元信息一條簡單的用戶緩存可能膨脹到幾KB內存浪費嚴重。這在開發(fā)階段還能忍上了生產就是事故。比如你發(fā)版時改了實體類的字段舊緩存的二進制流反序列化直接拋異常緩存層級崩潰數(shù)據(jù)庫瞬間被打爆。2.2 用GenericJackson2JsonRedisSerializer做全局序列化eladmin的RedisConfig應該重寫兩個BeanRedisTemplate和StringRedisTemplate。核心思路是key序列化用StringRedisSerializer保證可讀性。value序列化用GenericJackson2JsonRedisSerializer把對象轉成JSON字符串存儲兼容性好且能通過class字段保存類型信息反序列化時不丟類型。hash的key和value也分別指定序列化器。一個我實際在用的配置如下Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // key 使用 String 序列化 StringRedisSerializer stringSerializer new StringRedisSerializer(); GenericJackson2JsonRedisSerializer jsonSerializer new GenericJackson2JsonRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }這里有個細節(jié)GenericJackson2JsonRedisSerializer默認會把類型信息寫在JSON的class字段里。如果你緩存的對象里有接口類型、父類引用或者泛型反序列化時這一手非常關鍵。但它也不是萬能的遇到LocalDateTime這類Java 8時間類型時容易出問題一個常見的坑是序列化后變成數(shù)組格式。我在eladmin里處理這種場景時會在ObjectMapper里注冊JavaTimeModule并調整日期序列化的格式避免前后端解析不一致。2.3 緩存key的設計規(guī)范序列化只是第一步key的命名同樣重要。Redis是鍵值存儲沒有表結構約束key設計是否規(guī)范直接決定后續(xù)運維的體驗。我在eladmin里定的規(guī)范是業(yè)務域:模塊:唯一標識例如auth:token:{userId}用戶會話sys:dict:{dictName}字典緩存sys:dept:tree部門樹緩存lock:task:{taskName}定時任務的分布式鎖這樣用Redis Desktop Manager或者命令行SCAN匹配前綴時非常清晰也能通過命名空間做批量清理。另外key盡量短一些能用ID就不拼長字符串節(jié)省內存也提高查詢效率。2.4 配置完成后的最小驗證配置改完后不要急著寫業(yè)務先做一個最小驗證SpringBootTest public class RedisTest { Resource private RedisTemplateString, Object redisTemplate; Test public void test() { redisTemplate.opsForValue().set(auth:token:1, hello-redis); Object value redisTemplate.opsForValue().get(auth:token:1); System.out.println(value); } }跑通這一步再去Redis客戶端看key是否可讀、value是不是JSON字符串。如果看到類似hello-redis的文本內容就說明序列化配置生效了。提示不要用RedisTemplate直接存泛型對象比如ListUser如果JSON里只存了class到List內部元素類型容易丟失。穩(wěn)妥做法是自定義一個帶類型包裝的DTO或者用redisTemplate.opsForValue().set(key, JSON.toJSONString(list))配合反序列化手動指定類型。3. 緩存注解和RedisUtils兩種緩存方式的邊界3.1 Cacheable適合哪些業(yè)務eladmin里大量使用Spring Cache的注解緩存比如Cacheable、CacheEvict。注解方式的好處是侵入性小業(yè)務代碼里不用手寫存取邏輯。適合以下幾類字典類型列表按類型名緩存。部門樹、菜單樹按用戶ID緩存。系統(tǒng)配置項按配置鍵緩存。角色權限集合按角色ID緩存。一個典型例子Cacheable(value sys:dict, key #type, unless #result null) public ListDictDetail getDictDetails(String type) { // 數(shù)據(jù)庫查詢 }這樣第一次查詢后結果進入Redis后續(xù)請求直接命中緩存。但注解緩存有幾個隱藏問題我后面還會講失效時間不好精細控制、緩存擊穿場景下注解幫不上忙、更新時機容易亂。3.2 eladmin里的RedisUtils手動緩存eladmin原生的RedisUtils工具類是非常實用的封裝它把常用的set、get、delete、exists、expire都包了一遍并在設置值時自動指定過期時間。對于簡單的數(shù)據(jù)我建議直接用這個工具類而不是每個地方都寫redisTemplate.opsForValue().xxx()。手動緩存適合以下場景數(shù)據(jù)短生命周期比如登錄驗證碼5分鐘有效。需要精細控制過期時間。緩存數(shù)據(jù)需要在業(yè)務中頻繁更新比如在線用戶狀態(tài)。數(shù)據(jù)緩存與數(shù)據(jù)庫更新之間需要手動維護一致性注解方式很難表達“先改庫再刪緩存”的順序。舉個eladmin里的實際例子登錄成功之后把用戶信息塞進Redis設置30分鐘過期每次請求時刷新過期時間實現(xiàn)“滑動續(xù)期”。這個需求用Cacheable做不到因為注解緩存不支持動態(tài)刷新TTL但RedisUtils可以輕松完成。3.3 緩存更新機制優(yōu)先刪而不是更新這是我吃了虧才明白的道理。很多人寫完緩存后想當然地認為數(shù)據(jù)庫更新后把Redis值也更新就好了。但緩存更新的路數(shù)很多組合方式容易出錯。比如先更新數(shù)據(jù)庫還是先更新緩存、失敗了怎么辦、并發(fā)下會不會讀到舊值。eladmin業(yè)務里我統(tǒng)一采用“先更新數(shù)據(jù)庫再刪除緩存”的策略。下一請求發(fā)現(xiàn)緩存未命中再回源數(shù)據(jù)庫重建緩存。這個策略在大多數(shù)讀多寫少的后臺系統(tǒng)里足夠用而且天然避免了“寫緩存失敗導致數(shù)據(jù)不一致”的問題。刪除緩存這個動作本身也是冪等的就算刪晚了也只是多一次數(shù)據(jù)庫查詢。3.4 字典緩存的完整案例以eladmin的字典模塊為例它的查詢頻率很高但字典數(shù)據(jù)基本穩(wěn)定。如果每次查字典都走數(shù)據(jù)庫查詢接口響應會受DB性能影響。我的處理方式啟動時預熱項目啟動后調用一次字典查詢接口把常用字典寫進Redis。查詢時先查緩存命中直接返回。后臺編輯字典后調用刪除緩存接口保證下次查詢回源。這里有一個細節(jié)分頁查詢的字典列表不適合直接整體緩存因為分頁排序條件太多緩存命中率低還會造成緩存key爆炸。我只對“按字典名稱查詢所有明細”這種固定場景做緩存列表頁不緩存Excel導出也不緩存。緩存不是越多越好命中率低的緩存不僅浪費內存還增加了維護成本。4. 分布式鎖從緩存組件到協(xié)調組件4.1 為什么單機鎖不夠eladmin里的定時任務、庫存扣減類操作在單機部署時用Synchronized或ReentrantLock沒問題。但項目上了集群同樣的定時任務會在每個節(jié)點各執(zhí)行一遍造成重復數(shù)據(jù)。比如定時同步訂單狀態(tài)如果兩臺機器同時跑數(shù)據(jù)庫可能被更新兩次產生臟數(shù)據(jù)。單機鎖只對本進程生效這時就需要一個跨進程的鎖分布式鎖。Redis實現(xiàn)分布式鎖是最常見的方案因為它本身是共享存儲所有節(jié)點都能訪問且提供了原子操作。4.2 用Redis手寫一個可用的分布式鎖最簡單可靠的方案就是基于SET key value NX EX seconds這個命令能同時保證“key不存在才設置”和“過期時間自動設置”。用RedisTemplate實現(xiàn)如下public boolean tryLock(String key, String requestId, long expireSeconds) { // NX: 不存在才設置 EX: 設置過期時間 // 注意 SET_IF_ABSENT NX, SET_ABSENT_TIME EX Boolean result redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); return Boolean.TRUE.equals(result); } public boolean releaseLock(String key, String requestId) { // 使用Lua腳本保證“校驗持有者再刪除”是原子操作 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, List.of(key), requestId); return Long.valueOf(1).equals(result); }這里有兩個關鍵點requestId可以是UUID是鎖持有者的唯一標識。釋放鎖時必須校驗這個標識防止“自己不持有的鎖被自己刪掉”。用Lua腳本包裹“檢查-刪除”操作保證原子性。如果拆成兩步可能在GET之后、DEL之前鎖到期被另一個線程搶走然后你把別人的鎖刪了。4.3 鎖的續(xù)期問題和Redisson選擇手寫鎖有個麻煩業(yè)務執(zhí)行時間超過鎖的過期時間怎么辦比如加鎖時設了30秒但業(yè)務跑了40秒鎖自動釋放另一個線程進來了。解決思路是續(xù)期——在鎖即將到期但業(yè)務還沒結束時自動延長過期時間。這個邏輯很煩不建議手寫。我在這塊直接引入了Redisson它內置了看門狗機制默認鎖續(xù)期到30秒每10秒檢查一次業(yè)務沒結束就自動續(xù)期業(yè)務結束就釋放鎖。代碼反而簡單很多RLock lock redissonClient.getLock(lock:task:syncOrder); boolean isLocked lock.tryLock(3, 10, TimeUnit.SECONDS); if (isLocked) { try { // 業(yè)務邏輯 } finally { lock.unlock(); } }引入Redisson的代價是加一個依賴和一點內存但省去了自己處理續(xù)期、重入、異常釋放的雜活。eladmin里如果已經有Redisson依賴優(yōu)先用它的tryLock如果沒有手寫一個簡單的也夠用。提示手寫鎖務必設置過期時間絕不能只用setIfAbsent(key, value)不帶過期時間。一旦分布式鎖的key沒有過期時間而持有鎖的服務宕機這個鎖就永遠解不開了下游業(yè)務全部卡死。4.4 鎖定在eladmin里的實際場景我在eladmin里落地分布式鎖最多的場景是定時任務。eladmin有定時任務管理模塊可以動態(tài)啟停任務但任務本身可能被多個節(jié)點同時觸發(fā)。處理方式任務執(zhí)行入口先嘗試獲取鎖。搶到鎖的節(jié)點執(zhí)行任務沒搶到的節(jié)點直接跳過。執(zhí)行完成后主動釋放鎖。另外批量導入導出、文件分片合并、訂單狀態(tài)機轉換這類場景也需要鎖。核心思路是凡是“多實例下同一時間只允許一個執(zhí)行”的操作都值得用分布式鎖。5. 緩存三大故障現(xiàn)場穿透、擊穿、雪崩的解決實錄5.1 緩存穿透不存在的key瘋狂打庫eladmin里權限校驗接口如果被惡意刷每次都會攜帶一個不存在的用戶ID查數(shù)據(jù)庫Redis里始終沒有緩存數(shù)據(jù)庫壓力直線上升。這種查詢一個“必然不存在的數(shù)據(jù)”的現(xiàn)象就是緩存穿透。最常用的兩個辦法緩存空值查詢結果為空也寫緩存設置一個較短的過期時間比如60秒這樣后續(xù)相同Key不會打到DB。但要注意空值過多會占用內存需要設置過期時間。布隆過濾器把所有合法的用戶ID加載到布隆過濾器查詢前先判斷ID是否存在不存在直接返回。適用于ID集合較小且相對固定的場景。我在eladmin里處理驗證碼校驗接口時用的就是緩存空值方案驗證碼錯誤就緩存一個錯誤標記過期時間比驗證碼本身還短。這樣既保護了數(shù)據(jù)庫又不會影響正常用戶的重新發(fā)送。5.2 緩存擊穿熱點key瞬間過期打崩DB緩存擊穿和穿透容易混淆擊穿指的是某個熱點key在過期瞬間大量并發(fā)請求同時回源數(shù)據(jù)庫。比如eladmin的系統(tǒng)配置緩存如果剛好在零點過期所有請求都去查數(shù)據(jù)庫一次就夠數(shù)據(jù)庫喝一壺。解決手段通常有兩種互斥重建用分布式鎖包住回源邏輯只允許一個線程回源數(shù)據(jù)庫寫緩存其他線程等待緩存重建完成。缺點是鎖等待會增加接口耗時。邏輯過期緩存中不設置物理過期時間而是存一個邏輯過期戳。查詢時發(fā)現(xiàn)戳已經過期就異步重建。優(yōu)點是接口永遠有數(shù)據(jù)可返回但實現(xiàn)稍復雜。在eladmin的字典緩存里我采用的是折中方案熱點key的物理過期時間拉長到小時級后端修改字典后通過ActiveMQ或者直接調用刪除緩存接口來維護一致性避免“自然過期”引發(fā)擊穿。這個方案簡單但依賴“刪除操作必須可靠”。5.3 緩存雪崩大量key同一時刻失效雪崩和擊穿的區(qū)別在于影響范圍。雪崩是大批key在同一時間過期或者Redis服務整體不可用導致數(shù)據(jù)庫瞬間被沖垮。解決辦法我總結三條過期時間加隨機抖動比如基礎過期時間300秒實際設置時加一個0到60秒的隨機數(shù)避免同一秒集體失效。eladmin里的緩存工具類我已經統(tǒng)一封裝了這個邏輯。多級緩存配合Redis之上加一層本地緩存Caffeine本地緩存失效再查RedisRedis失效再查DB。這樣即使Redis短時間不可用本地緩存還能扛一部分。Redis高可用部署主從加哨兵或者Redis Cluster避免單點故障。這個我放在第6節(jié)詳細講。5.4 曾經踩過的坑INCR在分布式環(huán)境下的“不準”熱詞里有一條“redis incr不準”我在eladmin里也遇到過。場景是短信驗證碼發(fā)送頻率限制Long count redisTemplate.opsForValue().increment(limit:sms: phone); redisTemplate.expire(limit:sms: phone, 60, TimeUnit.SECONDS);這段代碼在單機Redis下沒有問題。但在主從架構下主機自增后同步給從機如果主機宕機、從機頂上自增的值可能丟失或重復導致計數(shù)不準。解決方案有幾個使用Redis Cluster的單一分片鎖住key的哈希槽保證只有一臺機器處理該key。頻率限制場景可以接受誤差時改成SETNX 過期時間判斷邏輯?；蛘咴赗edis事務Pipeline中執(zhí)行減少錯誤概率。另外INCR和EXPIRE是兩個獨立命令如果想讓key自動過期最好用Lua腳本把兩個操作包起來保證原子性否則極端情況下可能key永不過期計數(shù)累加超過預期。提示eladmin的接口限流功能如果用了IP計數(shù)千萬不要用get再set的復合操作必須用原生INCR。兩步操作在并發(fā)下會丟失增量計數(shù)這是非常隱蔽的一類bug。6. 從單機到集群eladmin上線后的Redis部署升級路線6.1 單機版夠用嗎開發(fā)環(huán)境和日活幾千的小項目單機Redis完全夠用。eladmin這種后臺系統(tǒng)數(shù)據(jù)庫字段多、接口讀寫比例高單臺8G內存的Redis實例支撐幾百個并發(fā)是沒問題的。但是單機的問題在于故障域。Redis宕機所有緩存全部失效數(shù)據(jù)庫被瞬時打滿整個系統(tǒng)雪崩。而且一臺機器上Redis進程如果OOMRedis會直接拒絕寫入進而影響所有依賴Redis的業(yè)務。因此正規(guī)一點的項目都會考慮主從。6.2 主從加哨兵怎么配更穩(wěn)主從模式解決的是“單點故障”哨兵解決的是“自動故障轉移”。我在eladmin生產環(huán)境用的一主二從加三哨兵架構主節(jié)點負責讀寫。從節(jié)點負責讀擴展和備份。哨兵監(jiān)控主從狀態(tài)主節(jié)點宕機后自動從從節(jié)點選舉出一個新主節(jié)點修改客戶端配置的地址指向新主節(jié)點。Spring Boot里配置Sentinel模式的地址很簡單spring: data: redis: sentinel: master: mymaster nodes: - 192.168.1.10:26379 - 192.168.1.11:26379 - 192.168.1.12:26379注意哨兵模式下應用連接的是哨兵地址而不是Redis節(jié)點地址。哨兵會告訴你當前可寫的主節(jié)點是誰。這塊如果配錯應用會一直連不上Redis日志里反復報Connection refused。主從復制還有一個核心點需要注意replica-read-only建議設置為yes。從節(jié)點只做讀寫操作全部走主節(jié)點否則可能會發(fā)生數(shù)據(jù)不一致。6.3 什么時候值得上ClusterRedis Sentinel解決的是“故障轉移”但單節(jié)點的內存容量上限還在。當緩存數(shù)據(jù)量大到單節(jié)點內存裝不下或者寫入并發(fā)超過單實例上限時就該考慮Redis Cluster。Cluster采用分片存儲每個key根據(jù)CRC16算法映射到16384個哈希槽中的某一個然后哈希槽分配給不同節(jié)點。好處是容量和性能都線性擴展壞處是配置復雜、客戶端要支持Cluster模式且Redis Cluster不支持多key操作除非這些key在同一個Hash標簽下。eladmin項目的緩存體量通常到不了Cluster的規(guī)模但如果未來做多租戶、數(shù)據(jù)量暴漲可以提前把key的Hash Tag設計好比如把所有需要一起操作的key都加上{user:1}這樣的Hash前綴確保它們落在同一個槽里。這個設計越早做越省事。6.4 Docker部署Redis時的常見錯誤很多團隊用Docker部署Redis熱詞里提到的“docker search redis request returned 500 internal server error”我碰到過多次。這個報錯通常是Docker Desktop的引擎沒起來或者API版本不兼容解決辦法是重啟Docker Desktop或者檢查Docker引擎的版本。真正進入docker pull redis階段之后還需要注意掛載持久化目錄比如/data防止容器重啟后數(shù)據(jù)丟失。指定Redis密碼和配置文件不要用默認無密碼的配置。如果宿主機和Redis容器不在同一網(wǎng)絡需要注意防火墻和端口映射。用Docker Compose部署一主二從加哨兵集群是本地復現(xiàn)和學習的好方式比手動敲命令省心很多。但這個更多是運維話題本文就不展開了。7. 體檢清單慢查詢、大key和熱點key的排查手段7.1 Redis慢查詢日志怎么看Redis的慢查詢日志和MySQL的slow query log思路類似。配置項slowlog-log-slower-than設置超時閾值單位微秒slowlog-max-len設置日志條數(shù)。執(zhí)行SLOWLOG GET可以查看最近慢查詢命令。eladmin的緩存基本都是小Key很少有長命令但如果有KEYS *這類命令出現(xiàn)在慢查詢里基本可以斷定代碼有問題。Redis是單線程的一個耗時的KEYS命令會阻塞所有客戶端響應線上絕不能執(zhí)行。我見過有人用KEYS auth:token:*來批量清理用戶會話導致Redis卡了幾秒所有依賴緩存的接口全部超時。正確做法是用SCAN游標遍歷分批次刪除。7.2 大key是隱藏的內存炸彈大key通常指value特別大的key比如一個Hash里塞了幾十萬個字段或者一個String存了幾MB的數(shù)據(jù)。大key會導致Redis內存碎片增加、刪除/序列化耗時變長還會在主從復制時造成網(wǎng)絡帶寬壓力。在eladmin里最常見的兩個大key場景緩存的用戶權限集合沒有控制大小一個超管用戶的權限菜單串成一個大JSON。字典緩存把所有數(shù)據(jù)一股腦塞進一個key而不是按類型拆分。排查手段用redis-cli --bigkeys它會掃描找出大key并給出類型和建議。治理方式很直接大key拆小key、續(xù)期策略調整、數(shù)據(jù)結構優(yōu)化。比如權限集合按角色拆分字典按類型拆分。7.3 內存淘汰策略的選擇Redis內存寫滿后怎么辦配置maxmemory-policy決定了淘汰策略。后臺管理系統(tǒng)里我推薦volatile-lru只在設置了過期時間的key里淘汰最近最少使用的數(shù)據(jù)。這樣業(yè)務緩存是“可淘汰”的但正在使用的會話數(shù)據(jù)不會被強制清掉。相比之下allkeys-lru會對所有key做淘汰包括你不想丟的業(yè)務緩存可能導致關鍵數(shù)據(jù)意外消失。還有一點maxmemory不要設成Redis所在服務器的全部內存要留出一部分給操作系統(tǒng)、其他進程防止Redis OOM把整臺服務器壓垮。我一般給Redis分配機器內存的60%-70%左右。7.4 可視化工具和日常巡檢建議命令行工具就是redis-cli圖形化工具我常用Another Redis Desktop Manager和Redis Insight。選工具主要看是否支持連接哨兵、Cluster、SSH隧道。日常巡檢建議做成定時腳本每天掃一遍INFO memory查看內存使用率。INFO replication查看主從復制狀態(tài)確認沒有斷連。INFO stats看連接數(shù)和命中率。SLOWLOG GET 50檢查慢命令。這些指標配合Prometheus和Grafana可以做到很完善的監(jiān)控但哪怕沒有專業(yè)監(jiān)控系統(tǒng)定時敲一下命令也比完全不看強一百倍。Redis掛了不可怕可怕的是你不知道它什么時候開始變慢、內存什么時候開始飆升。結尾經驗這套東西從頭到尾梳理下來我覺得在eladmin里用好Redis的關鍵只有兩點一是序列化和key設計必須在一開始就定好規(guī)范這個決定后續(xù)所有緩存代碼的體驗二是把分布式鎖、緩存擊穿、集群部署這些“進階能力”當作標配去考慮而不是等出了事故再補。我經歷過Redis配置亂碼導致生產環(huán)境接口直接500的夜晚也經歷過分布式鎖誤刪把定時任務數(shù)據(jù)弄亂的尷尬?，F(xiàn)在已經養(yǎng)成的習慣是任何redisTemplate的讀寫都先問自己“key規(guī)范嗎序列化對嗎過期時間設了嗎這行代碼在集群下還成立嗎”這四個問題能擋住絕大部分線上事故。希望這篇實踐對正在折騰eladmin的朋友有幫助。