最近在給客戶做若依分離版項目的交付客戶現(xiàn)場是嚴格的內(nèi)網(wǎng)環(huán)境安全審計那邊明確說了除了業(yè)務數(shù)據(jù)庫之外不允許再單獨部署 Redis 這類中間件。結(jié)果一上來就遇到個尷尬場面登錄頁驗證碼轉(zhuǎn)圈后臺日志刷屏“Unable to connect to Redis”。因為這版項目用的是若依分離版RuoYi-Vue默認把驗證碼、登錄 Token 這些關鍵數(shù)據(jù)都存在 Redis 里一旦 Redis 沒起來別說業(yè)務接口連登錄門都進不去。既然環(huán)境不讓用 Redis我干脆研究了一下怎么把這套分離版里的 Redis 徹底摘掉讓應用只依賴 MySQL 也能正常跑。這篇文章把整個改造過程完整記錄一下。核心思路其實很簡單若依的業(yè)務代碼并不直接操作 RedisTemplate而是通過一個叫 RedisCache 的工具類訪問緩存。我把這個工具類保留下來類名包名都不動把底層改成基于 ConcurrentHashMap 的本地內(nèi)存緩存這樣驗證碼、登錄會話、在線用戶這些功能都能繼續(xù)工作業(yè)務代碼幾乎零改動。下面的內(nèi)容會從原理到實操一步步來適合單機部署、演示環(huán)境、內(nèi)網(wǎng)交付的場景想給若依減負的可以照著做。1. 為什么若依分離版離不開 Redis1.1 若依把 Redis 用在了哪幾個關鍵位置先弄清楚 Redis 在若依分離版里到底承擔了什么不然改造的時候容易漏。我將 RuoYi-VueVue2/Vue3 分支邏輯基本一致依次檢查代碼定位到這幾個核心使用點登錄驗證碼獲取驗證碼圖片時生成一個 uuid把驗證碼答案存到 Redis提交登錄時再根據(jù) uuid 從 Redis 讀出答案校驗校驗成功后立即刪掉保證驗證碼一次性有效。登錄用戶會話登錄成功之后后端創(chuàng)建一個 uuid 作為 token把這個 token 作為 key把封裝好的 LoginUser 對象作為 value 存到 Redis前端每次請求攜帶 token后端通過 JWT 過濾器解析出這個 uuid再從 Redis 拉取 LoginUser 完成認證。會話滑動續(xù)期若依對登錄會話默認有 30 分鐘有效期但并不是固定 30 分鐘打死不變而是每次請求都刷新過期時間這也就是常說的滑動過期。這個刷新動作同樣操作 Redis 的過期時間。在線用戶管理管理端的在線用戶列表、強退用戶功能本質(zhì)上是掃描 Redis 里所有 login_tokens: 前綴的 key再把對應的 LoginUser 還原出來展示。除了這四處不同版本可能還有字典緩存、參數(shù)配置緩存、定時任務分布式鎖等二次封裝但最核心、繞不開的就是驗證碼和登錄會話。你可以在 IDEA 里直接全局搜索redisCache.把當前分支下所有調(diào)用點列出來心里先有個底。搞清楚這些之后你會發(fā)現(xiàn)若依的 Redis 依賴其實非常集中。它不像有些項目把一堆業(yè)務數(shù)據(jù)都往 Redis 里塞而是只處理“會話相關”和“校驗相關”的臨時數(shù)據(jù)。這個特點決定了我們后續(xù)用內(nèi)存緩存替換是可行的因為這些數(shù)據(jù)本來就不需要長期持久化重啟丟了也沒關系用戶重新登錄一次就好。1.2 去 Redis 適合什么場景不適合什么場景把 Redis 去掉不是所有情況下都合理先說清楚邊界免得你改完上線后發(fā)現(xiàn)問題又回不來。適合的場景有這么幾類第一類是單節(jié)點部署或者場景上本來就是單機演示、驗收環(huán)境不需要多個應用實例共享會話狀態(tài)第二類是客戶內(nèi)網(wǎng)環(huán)境安全要求嚴格不允許安裝保留無關中間件第三類是部署機器資源緊張希望簡化運維應用啟動后只依賴一個 MySQL第四類是本地開發(fā)調(diào)試不想每次先折騰 Redis 環(huán)境。不適合的場景也很明確多實例部署時內(nèi)存緩存只在單實例內(nèi)有效用戶第一次請求落在實例 A第二次落到實例 BToken 就找不到了會話直接斷掉已有在線用戶統(tǒng)計、強制踢人、多端登錄互斥等依賴 Redis 全局查詢和刪除功能的重度需求簡單替換會破壞這些能力微服務版本RuoYi-Cloud / RuoYi-Cloud-Plus里的 Redis 還承載著服務間緩存、分布式鎖、認證中心數(shù)據(jù)簡單替換會連累一堆功能Plus 系列版本對 Redis 的依賴更深比如 Sa-Token 會話集成、參數(shù)配置實時緩存等也不推薦按本文方式處理。一句話總結(jié)這個方案是給“單機輕量交付”準備的不是給所有若依項目一刀切用的。你只需要根據(jù)自己手上的部署形態(tài)做判斷。我這次客戶是兩臺服務器但只跑一個應用加一個 MySQL完全滿足條件。2. 動手改造前先摸清 Redis 在項目里的落腳點2.1 找到依賴和配置大多數(shù)若依分離版項目里Redis 的接入位置很固定。pom.xml 里有一個 starter 依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependencyapplication.yml 里有一段 spring.redis 配置有的版本用 spring.data.redis看你的 Spring Boot 版本spring: redis: host: localhost port: 6379 password: database: 0 timeout: 10s lettuce: pool: min-idle: 0 max-idle: 8 max-active: 8 max-wait: -1ms這里有一個很容易忽略的點如果項目里用了 Lettuce 連接池pom.xml 可能還有一個 commons-pool2 依賴去掉 Redis 時連這個依賴也要一起清理。不然后續(xù)排查依賴沖突時容易一頭霧水更煩的是明明 Redis 代碼都刪干凈了還是有人往 classpath 里帶進來一堆多余的連接池類。2.2 列一張“緩存白名單”我習慣把項目里所有 Redis 相關的類先拉一張清單再逐個處理。以 RuoYi-Vue 3.8.x 左右的分支為例典型清單如下組件所在位置作用改造策略RedisConfigcom.ruoyi.framework.config配置 RedisTemplate 序列化直接刪除或注釋RedisCachecom.ruoyi.common.core.redis業(yè)務統(tǒng)一操作的緩存工具類保留類名改底層實現(xiàn)CaptchaControllercom.ruoyi.web.controller.common驗證碼生成與校驗入口使用 RedisCache邏輯不動TokenServicecom.ruoyi.framework.web.service登錄用戶會話管理使用 RedisCache邏輯不動CacheConstantscom.ruoyi.common.constant定義 login_tokens、captcha_codes 等 key 前綴保留這張表能讓你清楚地看到真正要改的其實只有 RedisCache其余業(yè)務類只要不直接注入 RedisTemplate都可以不動。所以“替身方案”天然成立。如果你們的代碼里有個別地方繞過 RedisCache 直接注入 RedisTemplate就需要把那些調(diào)用也改掉這是改造時唯一可能漏掉的風險點。搜索的時候建議用兩個關鍵字一個是redisCache.另一個是RedisTemplate。前者是業(yè)務調(diào)用后者是底層橋接。兩個都搜完改動面自然就清楚了。我見過的二次開發(fā)項目里最常見的翻車點就是有人寫了個自定義服務直接 Autowired 了 StringRedisTemplate 去存臨時數(shù)據(jù)這類代碼不搜 RedisTemplate 根本發(fā)現(xiàn)不了。3. 用內(nèi)存緩存寫一個“替身” RedisCache3.1 改造思路類名不變底層換掉為什么要保留 RedisCache 這個類名原因很直接若依整個框架里到處都在注入它驗證碼、TokenService、在線用戶、定時任務刷新等等全部依賴這個類。如果把它刪掉再新建一個 MemoryCache那所有注入點都要改工作量立刻翻倍而且很容易改漏。保留類名和包名只是把類內(nèi)部的 RedisTemplate 操作換成本地 Map 操作外部調(diào)用方一句都不用動這是落盤最穩(wěn)、回歸成本最低的改法。實現(xiàn)“本地內(nèi)存版 RedisCache”要回答三個問題數(shù)據(jù)怎么存過期時間怎么管理以及滑動過期怎么支持。數(shù)據(jù)存儲最自然的選擇就是 ConcurrentHashMapkey 用字符串value 用一個內(nèi)部類型把緩存對象和過期時間包在一起。過期時間管理就是每次寫入時記錄到期時間戳每次讀取時判斷是否過期已經(jīng)過期的當作不存在并順手刪掉也就是常說的惰性刪除?；瑒舆^期這一塊若依的 TokenService 會在每次請求時調(diào)用 expire 方法刷新過期時間所以實現(xiàn)里必須保留 expire 方法修改對應 key 的到期時間即可。搞懂這三個問題后實現(xiàn)就不難了。3.2 帶過期時間和并發(fā)安全的本地緩存實現(xiàn)我這次用 ConcurrentHashMap 手搓了一個輕量緩存完整代碼貼出來。注意這一段要根據(jù)你自己分支里 RedisCache 的方法簽名微調(diào)但大邏輯是一樣的package com.ruoyi.common.core.redis; import org.springframework.stereotype.Component; import java.util.Collection; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.TimeUnit; import java.util.stream.Collectors; Component public class RedisCache { /** * 內(nèi)部緩存條目value 是真實對象expireAt 是過期時間戳毫秒0 表示不過期 */ private static class CacheEntry { private Object value; private long expireAt; CacheEntry(Object value, long expireAt) { this.value value; this.expireAt expireAt; } boolean isExpired() { return expireAt 0 System.currentTimeMillis() expireAt; } } private final MapString, CacheEntry localCache new ConcurrentHashMap(); public T void setCacheObject(final String key, final T value) { setCacheObject(key, value, 0L, null); } public T void setCacheObject(final String key, final T value, final Integer timeout) { // 注意如果你當前分支的這個重載原本以秒為單位這里要改成 TimeUnit.SECONDS setCacheObject(key, value, timeout null ? null : timeout.longValue(), TimeUnit.MILLISECONDS); } public T void setCacheObject(final String key, final T value, final Long timeout, final TimeUnit timeUnit) { long expireAt 0L; if (timeout ! null timeUnit ! null) { expireAt System.currentTimeMillis() timeUnit.toMillis(timeout); } localCache.put(key, new CacheEntry(value, expireAt)); } SuppressWarnings(unchecked) public T T getCacheObject(final String key) { CacheEntry entry localCache.get(key); if (entry null) { return null; } if (entry.isExpired()) { localCache.remove(key); return null; } return (T) entry.value; } public boolean deleteObject(final String key) { return localCache.remove(key) ! null; } public long deleteObject(final Collection collection) { if (collection null || collection.isEmpty()) { return 0L; } long count 0L; for (Object key : collection) { if (key ! null localCache.remove(key.toString()) ! null) { count; } } return count; } public boolean expire(final String key, final long timeout) { return expire(key, timeout, TimeUnit.MILLISECONDS); } public boolean expire(final String key, final long timeout, final TimeUnit unit) { CacheEntry entry localCache.get(key); if (entry null) { return false; } entry.expireAt System.currentTimeMillis() unit.toMillis(timeout); return true; } public boolean hasKey(String key) { return getCacheObject(key) ! null; } public CollectionString keys(final String pattern) { String prefix pattern.endsWith(*) ? pattern.substring(0, pattern.length() - 1) : pattern; return localCache.keySet().stream() .filter(key - key.startsWith(prefix)) .filter(key - { CacheEntry entry localCache.get(key); return entry ! null !entry.isExpired(); }) .collect(Collectors.toList()); } }簡單說明幾個關鍵點CacheEntry 是內(nèi)部靜態(tài)類把業(yè)務對象和過期時間綁在一起避免為了存過期時間再搞額外的結(jié)構。setCacheObject 接收 Long timeout 和 TimeUnit 的重載是若依 TokenService 和驗證碼鏈路調(diào)用最多的方法要保證它正確換算成毫秒時間戳。getCacheObject 里做了惰性過期判斷已經(jīng)過期的就當沒命中并順手 remove 一下避免臟數(shù)據(jù)一直駐留。expire 方法用于改寫已有 key 的過期時間這個非常關鍵。若依每次請求都會調(diào)用它來做會話滑動續(xù)期漏掉這個實現(xiàn)登錄后 30 分鐘一到就會全體掉線。keys 方法用于在線用戶列表查詢實現(xiàn)對 login_tokens: 前綴 key 的掃描。Redis 原生支持模糊匹配本地 Map 就直接遍歷判斷前綴演示環(huán)境數(shù)據(jù)量小性能沒問題。寫完后先不要急著動業(yè)務代碼編譯一下看調(diào)用的地方能不能對上。如果你的分支里有其他方法在 RedisCache 里被直接調(diào)用而這里沒有編譯器會立刻報錯補上對應實現(xiàn)就行。3.3 別忘了給本地緩存做定時清理ConcurrentHashMap 版本的惰性刪除有一個缺陷如果某個 key 設置了過期時間但之后再也沒人訪問它這個 key 就會一直留在 Map 里。驗證碼場景尤其明顯用戶每次刷新驗證碼都會往里面塞一個新 key很多人不登錄也不填驗證碼2 分鐘過期時間過了之后這些 key 依然躺在內(nèi)存里。日積月累看起來只是內(nèi)存占用增加但 Map 越來越大長期運行終究是隱患。解決辦法很簡單加一個后臺清理任務每分鐘掃描一次把過期的 CacheEntry 清掉?？梢栽?RedisCache 類里直接用 Scheduled 注解也可以用一個 ScheduledExecutorService。我這里用的是最樸素的方式private final ScheduledExecutorService cleaner Executors.newSingleThreadScheduledExecutor(); public RedisCache() { cleaner.scheduleAtFixedRate(this::clearExpiredEntries, 1, 1, TimeUnit.MINUTES); } private void clearExpiredEntries() { long now System.currentTimeMillis(); localCache.entrySet().removeIf(entry - entry.getValue().expireAt 0 now entry.getValue().expireAt); }這段代碼會在類實例化時啟動一個后臺線程每分鐘把過期的條目清掉。注意不要用 new Thread 在那睡循環(huán)ScheduledExecutorService 是更穩(wěn)妥的選擇。如果你不想引入定時任務也可以在 setCacheObject 的時候不定期觸發(fā)清理但這樣做有個明顯問題寫入本身已經(jīng)很頻繁了再疊加全表掃描有點得不償失。一分鐘一次的后臺清理對演示環(huán)境完全夠用。4. 從依賴到業(yè)務鏈路逐層拆掉 Redis4.1 移除 pom 和配置文件里的 Redis確認新的 RedisCache 能編譯通過后開始從外部“拆線”。第一步把 pom.xml 里的 spring-boot-starter-data-redis 依賴注釋掉或刪除。這里不要心急注釋掉后先做一次 mvn compile看有沒有類直接引用了 org.springframework.data.redis 下的類。如果報錯說明還有地方繞過了 RedisCache 直接操作 RedisTemplate把這些類找出來改成使用 RedisCache或者直接注釋掉相關代碼。第二步打開 RedisConfig整個類的作用就是給 RedisTemplate 定制序列化策略。Redis 都不用了這個類自然可以刪掉或注釋。注意檢查 RedisConfig 里是否有 Bean 方法被其他地方注入如果有對應注入點也要處理。比如有些項目會在配置類里把 RedisTemplate 注入到其他組件里做緩存預熱這類代碼要一起清掉。第三步把 application.yml 里 spring.redis 整段配置注釋掉包括 lettuce 連接池和 commons-pool2 依賴。如果你是用 Nacos 管理配置那就要去配置中心把 redis 相關項清掉。很多人在這一步遇到一個坑pom 里的 Redis 依賴刪了但 RedisConfig 還在一啟動就報 ClassNotFoundException: RedisConnectionFactory。原因就是代碼里還引著 RedisTemplate。所以順序很重要先確認代碼層沒有 redis 相關 import再刪依賴最后清配置。4.2 驗證碼鏈路完全不用改若依分離版的驗證碼邏輯在 CaptchaController 和 SysLoginService 里。大致流程是前端請求 /captchaImage后端生成圖形驗證碼同時生成一個 uuid 作為 key把驗證碼答案存入緩存key 的格式是 captcha_codes:uuid。前端提交登錄表單時帶上這個 uuid 和用戶輸入的驗證碼。后端根據(jù) uuid 從緩存讀出正確驗證碼比對成功后立刻刪除緩存 key。因為這套流程走的是 redisCache.setCacheObject / getCacheObject / deleteObject而我們的 RedisCache 類名和這些方法簽名都沒變所以這段業(yè)務代碼完全不用動。驗證碼的 2 分鐘過期時間也會被本地緩存的 TTL 機制正確執(zhí)行。你可能會擔心以前驗證碼存在 Redis 里現(xiàn)在存在應用內(nèi)存里多個實例不共享怎么辦。這個在單節(jié)點部署下根本不成立只有一臺應用服務器驗證碼本來就存在同一份內(nèi)存里邏輯上是一致的。我自己在改造前還特意把驗證碼鏈路完整跑了一遍確認驗證碼生成、校驗、錯誤攔截、過期失效四個環(huán)節(jié)都正常才繼續(xù)往下走的。4.3 登錄會話鏈路靠 expire 續(xù)期保證不掉線TokenService 是本次改造的重頭戲雖然業(yè)務代碼不用改但我們要理解它背后的機制才能確認自家替身靠不靠譜。若依的登錄會話管理大概是這樣的登錄成功后生成一個 UUID 作為 token把 LoginUser 對象存入緩存key 為 login_tokens:uuid過期時間默認 30 分鐘同時把 token 塞進 JWT 返回給前端。前端每次請求在請求頭帶上 Authorization后端攔截器從 JWT 里解析出這個 uuid然后調(diào)用 redisCache.getCacheObject 拿 LoginUser。每次請求解析成功后TokenService 會調(diào)用 redisCache.expire 把過期時間重新刷新成 30 分鐘。用戶主動退出時調(diào)用 redisCache.deleteObject 刪除這個 key。換成內(nèi)存緩存后getCacheObject 返回的是同一個 LoginUser 對象引用expire 方法會把過期時間戳往后推 30 分鐘deleteObject 會從 Map 里移除 key。三個動作全部有對應實現(xiàn)所以會話邏輯可以無感切換。有一點要提醒LoginUser 對象里包含權限標識、角色集合、用戶信息等字段。以前走 Redis 序列化時這些對象要經(jīng)過 FastJson 或 JDK 序列化經(jīng)常出現(xiàn)類型轉(zhuǎn)換異常、循環(huán)引用、日期格式不對這樣那樣的坑?，F(xiàn)在直接存對象引用這些問題反而消失了。內(nèi)存緩存雖然犧牲了分布式共享能力卻把序列化包袱一并甩掉了。4.4 全局搜索 redisCache把所有隱藏調(diào)用點過一遍驗證碼、會話、在線用戶是明面上的三個大塊但不同版本的若依可能在下面這些地方也用了 RedisCache參數(shù)配置被修改后清理緩存字典數(shù)據(jù)緩存刷新代碼生成時的一些臨時狀態(tài)用戶狀態(tài)變更后刪除該用戶所有在線會話。處理方式是統(tǒng)一的在 IDEA 里全局搜索redisCache.把搜索結(jié)果逐條點開看一遍。只要調(diào)用的是 RedisCache 的方法我們新實現(xiàn)都有對應能力不用改。但如果某段代碼直接注入了 RedisTemplate 或者 StringRedisTemplate就要重點處理替換成 RedisCache 或者直接移除。若依默認項目里一般不會出現(xiàn)這種繞行寫法二次開發(fā)的代碼里經(jīng)常有所以這個排查步驟不能省。我當時就遇到了一個自定義的短信發(fā)送模塊直接用 StringRedisTemplate 做了發(fā)送頻率限制Redis 一拆它第一個炸。后來我把那段邏輯的限流存儲也挪進了 RedisCache用 hasKey 和 expire 組合實現(xiàn)才把問題解決。5. 我的實測過程與測試清單5.1 新分支改造順序記錄我建議動手前先拉一個分支出來比如 feat/remove-redis避免主分支改壞了沒法快速回退。這次我自己的改造順序是第一步在 IDEA 里全局搜索 RedisTemplate 和 redisCache記錄所有文件。第二步重建 RedisCache 類先編譯通過。第三步注釋 RedisConfig刪除 pom 里的 redis starter 和 commons-pool2。第四步清理 application.yml 的 spring.redis 配置。第五步啟動應用依次驗證驗證碼、登錄、自動續(xù)期、退出登錄、在線用戶列表。這個順序的核心原則是“先讓代碼不依賴 Redis 也能編譯再讓應用不連接 Redis 也能啟動最后驗證業(yè)務功能”。按照這個節(jié)奏來每一步出問題都能快速定位。如果反過來先刪依賴再改代碼編譯報錯會把你淹沒在幾十個紅叉里很難分清哪個是核心問題。把改動提交到分支的時候我習慣拆成三個 commit第一個是 RedisCache 替換實現(xiàn)第二個是依賴和配置清理第三個是問題修復和文檔補充。這樣后續(xù)如果要回滾可以精準回滾到某個環(huán)節(jié)不用整個分支一起回退。5.2 不裝 Redis 直接啟動這是最關鍵的一步驗證。改造完成后我在本地直接把 Redis 服務停掉然后啟動若依后端。正常情況下日志里不會出現(xiàn)任何 Redis 連接失敗的異常應用能順利注冊控制臺。如果還是看到 “Unable to connect to Redis” 之類的日志說明還有地方在啟動階段主動初始化 Redis 連接池要按第 4 章的思路繼續(xù)排查。我當時還碰到過一個特殊情況若依的在線用戶監(jiān)控頁、操作日志、登錄日志這幾個模塊本身沒有強制依賴 Redis但有些自定義工具類里加了個 PostConstruct 方法初始化 RedisTemplate導致應用啟動失敗。通過全局搜索 RedisTemplate 把這類代碼找出來注釋掉問題就解決了。這個搜索動作不要只在 src 目錄里搜resources 下的 XML 配置、Mapper 配置里也可能藏著對 Redis 相關 Bean 的引用都要看一眼。5.3 業(yè)務回歸測試清單去掉 Redis 后我按下面這份清單做了一遍回歸你可以直接拿去用甚至做成一個最簡單的冒煙測試腳本測試項操作方式預期結(jié)果驗證碼加載打開登錄頁驗證碼正常顯示后臺無異常日志驗證碼校驗輸入正確/錯誤驗證碼各一次正確可繼續(xù)登錄錯誤被攔截且驗證碼失效正常登錄賬號密碼登錄返回 token跳轉(zhuǎn)首頁接口訪問請求 /getInfo 等需要登錄的接口返回用戶信息不 401會話續(xù)期等待 25 分鐘后再次請求會話仍有效不要求重新登錄會話過期不操作等待超過 30 分鐘token 失效需要重新登錄退出登錄調(diào)用退出接口后再請求原 token 立即失效在線用戶管理端查看在線用戶列表能看到當前登錄用戶強制下線管理端執(zhí)行強退被強退用戶下次請求 401多用戶并發(fā)兩個賬號同時登錄兩個會話互不影響應用重啟重啟后端后再次登錄老 token 失效新登錄正常這套清單跑完基本可以確認改造對業(yè)務的影響范圍是可控的。尤其是“會話續(xù)期”這一項如果沒實現(xiàn) expire 方法或?qū)崿F(xiàn)有誤25 分鐘后就會踩到全員掉線的雷。我在第一次實現(xiàn)時就是因為 expire 里忘了把 entry 寫回 MapValue 是基本類型改完等于沒改導致測試跑到 30 分鐘整批掉線后來改成直接修改對象字段才解決。壓測方面我們用 JMeter 模擬了 200 個并發(fā)用戶同時登錄并持續(xù)調(diào)用接口的操作跑了 30 分鐘沒有出現(xiàn)會話丟失或驗證碼失效的問題。內(nèi)存緩存的讀寫性能本來就在微秒級比走一次網(wǎng)絡 RPC 快得多所以單機場景下完全不用擔心性能。6. 改造中的高頻坑位與再進一步的建議6.1 我踩過和見過別人踩的坑第一Integer timeout 的單位問題。若依不同分支里 RedisCache.setCacheObject(String key, Object value, Integer timeout) 這個重載的單位有差異有的是毫秒有的是秒還有的版本根本沒有這個重載。改造時如果不確定就去看原類里這個方法的實現(xiàn)把單位抄過來不要想當然。第二鍵掃描的實現(xiàn)。Redis 原生的 keys 命令支持、? 這類通配符我們本地實現(xiàn)里如果只做前綴匹配某些反向調(diào)用 keys(captcha_) 會出問題。好在若依業(yè)務里基本只用前綴模式比如 login_tokens:* 和 captcha_codes:*所以前綴匹配夠用。如果你的二開代碼里用了復雜通配符那要么擴展本地實現(xiàn)要么改用 Caffeine 這類功能更完整的緩存庫。第三在線用戶列表查不到數(shù)據(jù)。這個問題很隱蔽。若依的在線用戶功能會先 redisCache.keys(LOGIN_TOKEN_KEY *)再逐條 getCacheObject。如果 keys 實現(xiàn)里返回了過期 key 的集合而后面 getCacheObject 又返回 null前端列表里就會出現(xiàn)空行或奇怪的 null 數(shù)據(jù)。我在實現(xiàn)里特意在 keys 時也判斷了一遍過期狀態(tài)就是為了避免這種臟數(shù)據(jù)。第四多實例部署的幻覺。有人改完之后覺得挺好又把它部署到兩臺服務器上結(jié)果用戶登錄后請求負載均衡到另一臺機器就 401。這個方案只認單實例多節(jié)點必須上 Redis 或獨立共享緩存這一點沒得商量。如果你未來有擴容計劃改造前就要慎重或者順便把緩存層抽象成可切換接口后續(xù)再換 Redis 也容易。第五清理資源別忘了連接池依賴。pom 里 redis starter 刪了但 commons-pool2 還留著雖然不影響運行但冗余依賴會讓后續(xù)維護的人困惑。另外有些瘦身更新腳本會掃描依賴樹多出來的歷史依賴可能被安全掃描工具標記到時又要解釋半天。6.2 如果不想手寫緩存可以用 Caffeine 兜底如果你不想維護自己的 ConcurrentHashMap 緩存邏輯可以直接引入 Caffeine把 RedisCache 內(nèi)部的 Map 換成 Caffeine 的 Cache。代碼會更簡潔dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId /dependencyCacheString, Object cache Caffeine.newBuilder() .maximumSize(10000) .build();不過要注意Caffeine 的 expireAfterWrite 是固定過期時間如果要實現(xiàn)若依那種“每次請求刷新 30 分鐘”的滑動過期就得自定義 Expiry 或者每次訪問時重新寫一次 key實現(xiàn)起來比直接手寫 TTL 還要繞一些。對我來說在 RedisCache 這個門面類里用 ConcurrentHashMap 管理 TTL反而是最貼合若依現(xiàn)有調(diào)用習慣的做法。Caffeine 更適合那些不需要滑動過期、key 數(shù)量又很大的純緩存場景。如果你不想依賴任何第三方庫那么我上面給出的 ConcurrentHashMap 版本已經(jīng)足夠精簡它最大的好處是零依賴只靠 JDK 原生能力就能跑對部署環(huán)境的侵入最小。6.3 關于無狀態(tài) JWT 和 Plus 版本的再說明如果你的目標不僅僅是摘掉 Redis還想讓若依改成完全無狀態(tài)的 JWT 認證那改動面會大很多。若依目前 JWT 里只存了一個 uuid真正的 LoginUser 還是存在緩存里這樣可以隨時剔除用戶、統(tǒng)計在線。改成無狀態(tài)后權限數(shù)據(jù)全塞進 JWT每次請求直接解析雖然不用緩存了但也失去了主動踢人和會話過期的精細控制。除非有明確的性能或架構要求否則我不建議在這個方向上折騰收益不大改動和風險卻成倍增加。至于 RuoYi-Cloud 和 RuoYi-Cloud-Plus 這類微服務版本Redis 已經(jīng)深入到認證、分布式鎖、緩存一致性等環(huán)節(jié)簡單把 RedisCache 換成內(nèi)存緩存會導致服務間會話不互通、鎖失效、數(shù)據(jù)不一致等一系列問題。如果確實要降低部署復雜度更好的辦法是把 Redis 做成內(nèi)嵌模式或者用高可用的云數(shù)據(jù)庫而不是直接去掉。最后分享一個實際體會。若依框架把緩存訪問收斂到 RedisCache 這一個門面類上這個設計本來就給底層替換留了余地。我們這次用本地內(nèi)存緩存頂替 Redis本質(zhì)上是把“分布式緩存”換成了“單機緩存”業(yè)務代碼沒怎么動部署環(huán)境卻清爽了不少。改造過程中最值得投入時間的不是寫緩存代碼而是把項目里所有 redisCache 的調(diào)用點梳理清楚。梳理清楚了剩下的活基本就是照著業(yè)務需求選一種緩存實現(xiàn)而已。如果哪天項目要升到多節(jié)點把 RedisCache 的底層實現(xiàn)換回 Redis或者換成 Caffeine 加分布式緩存業(yè)務代碼依然不用怎么動只是到時候要跟運維確認好緩存服務的高可用方案就行。