SpringBootShiroRedis 整合實現(xiàn)用戶認證授權(quán)這套組合在中小型項目里實在太常見了。我自己接過好幾個這類需求真要說起來踩過的坑不比寫過的代碼少。如果你正準備給項目加一套登錄鑒權(quán)又不想直接上Spring Security那一大坨配置那Shiro配Redis確實是個非常務(wù)實的選擇。這篇文章就把我實際整合過程中的思路、配置、代碼和問題排查全部整理出來照著做可以少走很多彎路。1. 整體設(shè)計與思路拆解1.1 為什么選 Shiro 而不是 Spring Security很多剛開始做認證授權(quán)的同學會糾結(jié)這個問題。Spring Security背靠Spring家族功能確實強大社區(qū)資料也多但它的學習曲線偏陡峭過濾鏈的配置邏輯也比較繞新手往往花了兩三天連登錄流程還沒跑通。Shiro的設(shè)計哲學則相反它把認證、授權(quán)、會話管理、加密這幾個核心能力全部抽象成簡單的API概念少、上手快一個簡單的登錄校驗只需要理解Subject、SecurityManager、Realm這三個核心組件就能跑起來。從實際項目角度講如果你的系統(tǒng)是標準的單體應(yīng)用用戶量在百萬以下對安全框架的要求主要是“能快速實現(xiàn)登錄、記住我、角色權(quán)限控制”那Shiro是完全夠用的。它自帶SessionManager結(jié)合Redis之后還能解決分布式場景下的會話共享問題已經(jīng)覆蓋了絕大多數(shù)業(yè)務(wù)系統(tǒng)的需求。我見過不少公司內(nèi)部的管理后臺、運營系統(tǒng)、中小型電商后端用的都是這套方案。當然Shiro也不是沒有缺點。相比Spring Security它的過濾鏈自定義能力弱一些文檔也不夠細致遇到一些偏門問題往往要靠翻源碼解決。而且Shiro的社區(qū)活躍度近年有所下降新功能迭代比較慢。選型的時候你要評估自己的團隊情況如果大家都沒用過Shiro但熟悉Spring生態(tài)那直接上Spring Security可能反而更順如果項目工期緊、需求簡單或者團隊成員已經(jīng)有Shiro經(jīng)驗?zāi)荢hiro這套組合性價比極高。1.2 引入 Redis 解決了什么問題單機部署的時候Shiro自帶的Session管理完全夠用Session數(shù)據(jù)存在JVM內(nèi)存里登錄狀態(tài)直接保存在服務(wù)器本地?？梢坏┫到y(tǒng)需要多節(jié)點部署或者服務(wù)重啟、發(fā)布問題就來了用戶在A節(jié)點登錄下次請求被負載均衡轉(zhuǎn)發(fā)到B節(jié)點B節(jié)點的內(nèi)存里沒有這個Session用戶就被判定為未登錄體驗非常割裂。傳統(tǒng)的解決方案是Session黏滯讓同一個用戶的請求始終轉(zhuǎn)發(fā)到同一臺機器但這只能算規(guī)避節(jié)點故障或重啟時問題依然存在。引入Redis之后Session數(shù)據(jù)被集中存儲在外部緩存中所有節(jié)點共享同一份會話數(shù)據(jù)。用戶無論請求到哪個節(jié)點都能從Redis正確讀取登錄狀態(tài)。同時Redis的高讀寫性能讓Session的存取幾乎不影響接口響應(yīng)時間。除了存SessionRedis還承擔了權(quán)限緩存的角色。Shiro默認每次請求都會執(zhí)行Realm的授權(quán)方法如果你的授權(quán)邏輯里有數(shù)據(jù)庫查詢在高并發(fā)場景下這個開銷會被放大。把角色和權(quán)限列表緩存到Redis后同一用戶的權(quán)限校驗直接命中緩存大幅減少了數(shù)據(jù)庫的壓力。這套設(shè)計在真正的生產(chǎn)環(huán)境里效果很明顯我有一次壓測加了Redis緩存之后QPS提升了將近30%。1.3 整體架構(gòu)與數(shù)據(jù)流轉(zhuǎn)過程這套方案的核心數(shù)據(jù)流轉(zhuǎn)可以簡單概括為請求進來Shiro過濾鏈判斷是否有登錄憑證有則從Redis中取出Session恢復用戶的登錄狀態(tài)需要鑒權(quán)時從Redis緩存取出權(quán)限信息進行校驗登錄成功后用戶信息和Session寫入Redis退出登錄時刪除Redis中的會話數(shù)據(jù)。具體到一次登錄請求的時序用戶提交用戶名密碼Shiro把請求包裝成一個UsernamePasswordToken交給SecurityManagerSecurityManager委托給配置好的Realm去做認證——Realm里我們寫的是先查數(shù)據(jù)庫用戶信息再用密碼加密規(guī)則比對密碼認證成功后Shiro根據(jù)配置生成Session并存入Redis同時用戶主體信息也被緩存起來。后續(xù)每次請求經(jīng)過過濾鏈時Shiro的SessionDAO都會先去Redis里查這個Session是否還存在從而判斷用戶是否有效登錄。這套流程把“認證”“會話”“緩存”三個環(huán)節(jié)通過Redis串起來結(jié)構(gòu)清晰每個環(huán)節(jié)都可以獨立做擴展。比如后續(xù)要加“記住我”功能只要調(diào)整Cookie和Session的有效期邏輯要加多終端登錄限制也只需在Session管理上做文章。2. 核心細節(jié)解析與實操要點2.1 Shiro 三大核心組件的工作機制Shiro的工作模型圍繞Subject、SecurityManager、Realm展開。用生活化的類比來解釋這三者的關(guān)系Subject是“當前操作的人”SecurityManager是“門衛(wèi)”Realm是“員工花名冊”。Subject代表當前用戶封裝了用戶的所有安全操作。在代碼里你可以隨時通過SecurityUtils.getSubject()拿到它然后用subject.login(token)做登錄用subject.isAuthenticated()判斷是否已登錄用subject.hasRole(admin)判斷角色。它本質(zhì)上是Shiro與當前線程綁定的一個上下文對象簡化了安全操作的調(diào)用方式。SecurityManager整個Shiro的心臟負責協(xié)調(diào)認證、授權(quán)、會話管理等所有內(nèi)部組件。它自己不干活而是把任務(wù)分發(fā)給其他組件執(zhí)行。在SpringBoot整合時我們需要在配置類里創(chuàng)建一個SecurityManager的Bean并把它綁定到Shiro的過濾鏈上。Realm數(shù)據(jù)訪問層的橋接器Shiro通過它獲取用戶的認證信息和授權(quán)信息。默認的Realm什么都不做我們必須寫一個自定義Realm繼承AuthorizingRealm重寫doGetAuthenticationInfo認證時用和doGetAuthorizationInfo授權(quán)時用這兩個方法。這是整個整合方案里最核心的代碼部分。理解這三個組件的職責邊界排起錯來會清晰很多。比如登錄失敗問題大概率出在Realm里的認證邏輯權(quán)限校驗不通過就要檢查doGetAuthorizationInfo里返回的權(quán)限集合是否正確。2.2 過濾鏈配置anon、authc、roles、perms 的含義Shiro的過濾鏈是通過配置URL和對應(yīng)的過濾器來實現(xiàn)訪問控制的這也是它最讓人頭疼但又最靈活的部分。常用的幾個過濾器要搞清楚anon匿名訪問不需要登錄就可以訪問。通常用來放行登錄接口、注冊接口、靜態(tài)資源、驗證碼接口。authc必須登錄后才能訪問。配置了authc的路徑如果用戶未登錄會被重定向到登錄頁面或返回未授權(quán)提示。roles必須擁有指定角色才能訪問。它需要參數(shù)比如roles[admin]表示只有admin角色可以訪問。perms必須擁有指定權(quán)限才能訪問同樣需要參數(shù)比如perms[user:add]。配置的順序非常重要。Shiro的過濾鏈是“第一次匹配優(yōu)先”的也就是說一條請求在前面匹配到了anon就會立刻放行后面的authc根本不會生效。我見過有同學把/**authc配置在前面結(jié)果所有請求都要登錄后面配置的放行規(guī)則完全失效。正確的做法是放行規(guī)則寫前面兜底的攔截規(guī)則寫最后具體化的路徑寫前面通配的路徑寫后面。2.3 Redis 在 Shiro 整合中的兩種核心用途Redis這套方案里扮演兩個完全不同的角色很多人在配置時容易混淆導致出現(xiàn)一些很隱蔽的問題。第一個用途是作為Session的存儲介質(zhì)。Shiro把原本存在JVM的Session搬到Redis里需要我們自己實現(xiàn)一個RedisSessionDAO繼承AbstractSessionDAO重寫doCreate、doRead、doUpdate、doDelete這幾個方法。Shiro每次創(chuàng)建、讀取、更新、刪除Session時都會調(diào)用這個DAO。寫入Redis的key我們通常設(shè)計成shiro_session_xxx這樣的格式value是序列化后的Session對象。第二個用途是權(quán)限數(shù)據(jù)的緩存。Shiro的Realm里有一個AuthorizationCache默認內(nèi)存實現(xiàn)。我們把它替換成RedisCache實現(xiàn)后用戶權(quán)限信息會以shiro_cache_xxx的key形式存入Redis緩存有效期可以單獨設(shè)置。兩種數(shù)據(jù)雖然都放在Redis里但生命周期和用途不一樣建議在Redis的key前綴上做明確區(qū)分避免相互干擾。2.4 序列化方案Java 序列化 vs JSON 序列化把Session對象和權(quán)限對象存入Redis之前必須經(jīng)過序列化。這里有個很多人踩過的坑RedisTemplate默認的序列化器是JdkSerializationRedisSerializer它要求存儲的對象必須實現(xiàn)Serializable接口。如果你的用戶實體類沒實現(xiàn)Serializable運行時就會拋序列化異常。用Java原生序列化雖然簡單但存儲的內(nèi)容可讀性極差全是亂碼和類路徑信息占用空間也大。更推薦的做法是用FastJson或Jackson做序列化這樣Redis里看到的是清晰的JSON結(jié)構(gòu)排查問題時一眼就能看出存儲的內(nèi)容。不過要注意用JSON序列化時從Redis讀出來的對象是JSON反序列化后的副本不是原來的對象引用在極端情況下可能存在數(shù)據(jù)一致性問題?？紤]到Session和權(quán)限信息通常是只讀使用這個權(quán)衡是可以接受的。我在生產(chǎn)環(huán)境里用的是改造過的RedisSessionDAO內(nèi)部統(tǒng)一走JSON序列化這樣Redis里的數(shù)據(jù)鍵值對一目了然出了問題的定位效率高很多。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 Maven 依賴引入首先在pom.xml里引入必要的依賴。我用的版本組合是經(jīng)過實際驗證的可以直接抄dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.apache.shiro/groupId artifactIdshiro-spring-boot-starter/artifactId version1.9.1/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-pool2/artifactId /dependency dependency groupIdcom.alibaba/groupId artifactIdfastjson/artifactId version2.0.26/version /dependency需要注意shiro-spring-boot-starter這個依賴在不同版本下的兼容性差異挺明顯。如果你用的是Spring Boot 2.x建議Shiro版本選1.8.x以上1.9.x更穩(wěn)如果你是Spring Boot 3.x那要特別注意Shiro對Jakarta命名空間的支持問題最好找專門的適配版本。3.2 自定義Realm實現(xiàn)認證與授權(quán)自定義Realm是整套方案的核心代碼。我習慣創(chuàng)建一個名為UserRealm的類繼承AuthorizingRealm里面實現(xiàn)認證和授權(quán)兩個方法。先看認證方法Override protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { UsernamePasswordToken usernamePasswordToken (UsernamePasswordToken) token; String username usernamePasswordToken.getUsername(); // 根據(jù)用戶名查詢數(shù)據(jù)庫 User user userService.findByUsername(username); if (user null) { throw new UnknownAccountException(用戶不存在); } if (user.getStatus() 0) { throw new LockedAccountException(賬號已被鎖定); } // 返回認證信息密碼的比對由CredentialsMatcher完成 return new SimpleAuthenticationInfo(user, user.getPassword(), ByteSource.Util.bytes(user.getSalt()), getName()); }注意這里有個關(guān)鍵設(shè)計我沒有在Realm里手動比對密碼而是把數(shù)據(jù)庫查出的加密密碼返回給Shiro由配置的CredentialsMatcher去自動比對。這樣做的好處是密碼校驗邏輯集中管理后續(xù)如果更換加密算法只需要替換Matcher的實現(xiàn)不影響Realm的其它邏輯。再看授權(quán)方法Override protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) { User user (User) principals.getPrimaryPrincipal(); SimpleAuthorizationInfo info new SimpleAuthorizationInfo(); // 查詢用戶角色 SetString roles roleService.findRolesByUserId(user.getId()); // 查詢用戶權(quán)限 SetString perms permissionService.findPermsByUserId(user.getId()); info.setRoles(roles); info.setStringPermissions(perms); return info; }這個方法的調(diào)用時機很特殊不是每次請求都會執(zhí)行而是首次訪問需要角色或權(quán)限校驗的接口時才觸發(fā)而且結(jié)果會被緩存。所以把權(quán)限查詢邏輯寫在這里非常合適配合Redis緩存可以大幅減少數(shù)據(jù)庫查詢。3.3 Shiro 核心配置類編寫配置類負責把Realm、SecurityManager、SessionDAO、過濾鏈全部串起來。我直接給出一個可以運行的配置骨架Configuration public class ShiroConfig { Bean public UserRealm userRealm() { return new UserRealm(); } Bean public SecurityManager securityManager(UserRealm userRealm, RedisSessionDAO sessionDAO) { DefaultWebSecurityManager manager new DefaultWebSecurityManager(); manager.setRealm(userRealm); manager.setSessionManager(sessionManager(sessionDAO)); // 開啟Redis緩存權(quán)限數(shù)據(jù) manager.setCacheManager(redisCacheManager()); return manager; } Bean public SessionManager sessionManager(RedisSessionDAO sessionDAO) { DefaultWebSessionManager sessionManager new DefaultWebSessionManager(); sessionManager.setSessionDAO(sessionDAO); // Session有效期單位毫秒這里設(shè)置為2小時 sessionManager.setGlobalSessionTimeout(7200000); return sessionManager; } Bean public ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager) { ShiroFilterFactoryBean factoryBean new ShiroFilterFactoryBean(); factoryBean.setSecurityManager(securityManager); // 登錄接口 factoryBean.setLoginUrl(/api/login); // 未授權(quán)跳轉(zhuǎn)地址 factoryBean.setUnauthorizedUrl(/api/unauthorized); // 過濾鏈配置 MapString, String filterChainDefinitionMap new LinkedHashMap(); // 放行登錄、注冊、驗證碼接口 filterChainDefinitionMap.put(/api/login, anon); filterChainDefinitionMap.put(/api/register, anon); filterChainDefinitionMap.put(/api/captcha, anon); // 靜態(tài)資源放行 filterChainDefinitionMap.put(/static/**, anon); // 用戶相關(guān)接口需要登錄 filterChainDefinitionMap.put(/api/user/**, authc); // 管理員接口需要admin角色 filterChainDefinitionMap.put(/api/admin/**, roles[admin]); // 增加權(quán)限示例 filterChainDefinitionMap.put(/api/user/add, perms[user:add]); // 其余接口需要登錄 filterChainDefinitionMap.put(/**, authc); factoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap); return factoryBean; } }有一處細節(jié)要提醒filterChainDefinitionMap的類型一定是LinkedHashMap保證有序性。如果用了HashMap過濾鏈的匹配順序會變得不可預(yù)測表面上看著配置沒問題實際跑起來卻會出現(xiàn)各種奇怪的訪問異常。另外CacheManager的Redis實現(xiàn)需要我們自己寫一個類繼承AbstractCacheManager創(chuàng)建RedisCache。這個類的代碼量不大核心是把Cache接口的get、put、remove方法映射到Redis的讀寫刪除操作上。3.4 RedisSessionDAO 與 RedisCache 實現(xiàn)這部分是整合過程中的硬骨頭直接給出可用的核心實現(xiàn)。RedisSessionDAO繼承AbstractSessionDAO關(guān)鍵是序列化方式。我選擇用FastJson處理先把Session轉(zhuǎn)成JSON字符串存入Redis讀取時再反序列化。還有一個細節(jié)是key的過期時間設(shè)置——Session本身有超時時間Redis的key也要設(shè)置一個對應(yīng)的TTL防止Session永久殘留在Redis里變成臟數(shù)據(jù)。Component public class RedisSessionDAO extends AbstractSessionDAO { Autowired private RedisTemplateString, String redisTemplate; private static final String SESSION_KEY_PREFIX shiro_session:; private static final long SESSION_TIMEOUT 7200L; Override protected Serializable doCreate(Session session) { Serializable sessionId generateSessionId(session); assignSessionId(session, sessionId); saveSession(session); return sessionId; } Override protected Session doReadSession(Serializable sessionId) { String key SESSION_KEY_PREFIX sessionId; String sessionStr redisTemplate.opsForValue().get(key); if (sessionStr null) { return null; } return JSON.parseObject(sessionStr, SimpleSession.class); } private void saveSession(Session session) { String key SESSION_KEY_PREFIX session.getId(); String sessionStr JSON.toJSONString(session); redisTemplate.opsForValue().set(key, sessionStr, SESSION_TIMEOUT, TimeUnit.SECONDS); } Override public void update(Session session) throws UnknownSessionException { saveSession(session); } Override public void delete(Session session) { String key SESSION_KEY_PREFIX session.getId(); redisTemplate.delete(key); } }RedisCache的實現(xiàn)稍微復雜主要是把緩存key映射到Redis key并統(tǒng)一管理過期時間。這里我直接用一個StringRedisTemplate操作避免序列化器不一致帶來的問題。3.5 登錄接口與退出登錄的實現(xiàn)登錄接口的邏輯很直觀核心就兩行代碼創(chuàng)建token調(diào)用subject.login。PostMapping(/login) public Result login(RequestBody LoginRequest loginRequest) { Subject subject SecurityUtils.getSubject(); UsernamePasswordToken token new UsernamePasswordToken( loginRequest.getUsername(), loginRequest.getPassword() ); try { subject.login(token); // 登錄成功后可以從subject里拿到用戶信息 User user (User) subject.getPrincipal(); return Result.success(登錄成功, user); } catch (UnknownAccountException e) { return Result.error(用戶不存在); } catch (IncorrectCredentialsException e) { return Result.error(密碼錯誤); } catch (LockedAccountException e) { return Result.error(賬號被鎖定); } catch (AuthenticationException e) { return Result.error(認證失敗); } }退出登錄更簡單一行代碼GetMapping(/logout) public Result logout() { Subject subject SecurityUtils.getSubject(); subject.logout(); return Result.success(退出成功); }調(diào)用subject.logout()之后Shiro會清掉當前Subject的身份信息并通過我們實現(xiàn)的RedisSessionDAO刪除對應(yīng)的Session數(shù)據(jù)。從Redis里檢查一下key對應(yīng)的數(shù)據(jù)是否被清掉就能確認退出邏輯是否生效。3.6 權(quán)限注解的使用方式除了過濾鏈配置Shiro還支持在接口方法上使用注解來控制權(quán)限粒度更細用起來也比URL配置更清晰。RestController RequestMapping(/api/user) public class UserController { // 需要登錄才能訪問 RequiresAuthentication GetMapping(/info) public Result getUserInfo() { User user (User) SecurityUtils.getSubject().getPrincipal(); return Result.success(user); } // 需要admin角色 RequiresRoles(admin) PostMapping(/delete) public Result deleteUser(RequestParam Long userId) { userService.deleteById(userId); return Result.success(刪除成功); } // 需要user:add權(quán)限 RequiresPermissions(user:add) PostMapping(/add) public Result addUser(RequestBody User user) { userService.add(user); return Result.success(新增成功); } }使用注解方式有個先決條件必須在配置類里開啟Shiro注解支持并且確保Shiro的攔截器配置了可代理的目標對象。Spring Boot整合Shiro后默認會通過AOP方式支持注解但需要額外加入一個Bean配置讓Spring的切面能夠攔截到這些注解。3.7 密碼加密方案的選型與實現(xiàn)密碼安全是整個認證系統(tǒng)里絕對不能含糊的部分。早期很多系統(tǒng)直接用MD5存密碼這在如今的安全環(huán)境下是遠遠不夠的。我推薦使用MD5加隨機鹽的方式甚至直接用BCrypt成本低效果好。以MD5加鹽為例注冊時生成一個隨機salt密碼加密的邏輯如下// 生成隨機鹽 String salt RandomStringUtils.randomAlphanumeric(8); // 加密迭代次數(shù)可以根據(jù)需要調(diào)整 String encryptedPassword new Md5Hash(rawPassword, salt, 2).toHex();數(shù)據(jù)庫里存儲的是加密后的密碼和鹽。登錄時Shiro會通過CredentialsMatcher進行密碼比對我們要在ShiroConfig的UserRealm里設(shè)置對應(yīng)的MatcherBean public UserRealm userRealm() { UserRealm realm new UserRealm(); // 使用帶鹽的MD5迭代2次 HashedCredentialsMatcher matcher new HashedCredentialsMatcher(); matcher.setHashAlgorithmName(MD5); matcher.setHashIterations(2); realm.setCredentialsMatcher(matcher); return realm; }這里面有一處非常容易踩坑HashedCredentialsMatcher默認認為數(shù)據(jù)庫里存儲的密碼是Hex字符串如果當時加密用的是Base64或者其他編碼比對就會一直失敗。所以注冊時的編碼方式和Matcher的預(yù)期必須嚴格一致改起來很費勁。如果要從根本上提高安全性可以直接用BCrypt。BCrypt的哈希自帶鹽不需要額外字段存salt校驗時直接用BCrypt.matches(rawPassword, encryptedPassword)即可。Shiro也有對應(yīng)的BCryptCredentialsMatcher可以配置。代價是BCrypt的計算開銷大一些但對登錄這種低頻操作來說完全不是問題。4. 整合過程中的常見問題與排查實錄4.1 Session 失效或每次請求都重新登錄這個問題的典型表現(xiàn)是前端調(diào)用登錄接口成功了但下一次請求就被過濾鏈攔截判定為未登錄。排查思路先檢查Redis里面有沒有寫入Session數(shù)據(jù)。如果Redis里根本沒有shiro_session開頭的key說明SessionDAO的寫入邏輯沒有被執(zhí)行或執(zhí)行失敗。常見原因有幾種RedisTemplate的序列化配置有問題Session對象寫入Redis時報序列化異常被Shiro內(nèi)部吞掉了。SessionDAO沒有正確注入到SessionManagerShiro還是用的默認內(nèi)存Session實現(xiàn)。檢查配置里sessionManager的setSessionDAO是否真的生效。Cookie的名稱或路徑不對瀏覽器沒有保存Shiro生成的SessionID。用瀏覽器的開發(fā)者工具看一下請求Cookie的情況。如果是前端部署在另外一個域名的場景還要考慮Cookie跨域的問題。Shiro默認的Cookie只在同域名下有效跨域時需要配置Cookie的domain屬性或者改成前后端分離模式前端手動攜帶SessionID。4.2 密碼一直匹配不上的問題密碼比對失敗的排查核心是注冊時的加密邏輯和登錄時的校驗邏輯必須完全一致。最常見的坑是加鹽方式不對。注冊時用new Md5Hash(password, salt, 2)但登錄時Matcher拿到的ByteSource如果不一致結(jié)果必然不一樣。在Realm里返回AuthenticationInfo時鹽的構(gòu)造方式必須和注冊時保持一致。比如注冊時用的是隨機字符串salt那么Realm返回時也要用ByteSource.Util.bytes(user.getSalt())。另外一個坑是迭代次數(shù)。我遇到過一個情況數(shù)據(jù)庫表里有歷史數(shù)據(jù)老數(shù)據(jù)的迭代次數(shù)是1次新數(shù)據(jù)是2次結(jié)果老用戶全部登錄失敗。解決思路是漸進式遷移登錄成功后檢測當前用戶的加密參數(shù)如果是老版本在登錄成功的同時用新參數(shù)重新加密一遍密碼并更新數(shù)據(jù)庫。4.3 Redis 緩存導致權(quán)限變更不生效這是最容易讓人困惑的問題之一。管理員在后臺修改了某個用戶的角色或者權(quán)限但該用戶下次訪問接口時還是舊權(quán)限甚至需要重啟服務(wù)才生效。原因是權(quán)限信息被緩存到了Redis而且是按用戶維度緩存的。只要不主動清理Redis中的緩存會一直沿用舊數(shù)據(jù)。解決思路有三種在權(quán)限變更的接口里主動清理對應(yīng)用戶權(quán)限的緩存。需要拿到權(quán)限緩存Manager調(diào)用clearCache方法。給權(quán)限緩存設(shè)置較短的過期時間比如30分鐘犧牲一些性能換取準實時性。在權(quán)限變更后強制該用戶重新登錄通過登錄流程重建權(quán)限緩存。實際項目里我比較推薦第一種思路在業(yè)務(wù)代碼里預(yù)留緩存清理邏輯。雖然要多寫一點代碼但權(quán)限變更的響應(yīng)是幾乎實時的運營和管理同事的體驗會好很多。4.4 RedisSessionDAO 反序列化報錯這種情況在Session數(shù)據(jù)是舊版本寫入、代碼升級后重新讀取時容易發(fā)生。比如之前用Java原生序列化寫入的Session代碼改成JSON序列化后舊的Redis數(shù)據(jù)還在新代碼嘗試用JSON解析直接拋異常。解決思路是平滑升級改代碼之前先把Redis里的Session數(shù)據(jù)一次性清掉。發(fā)布時設(shè)置session的有效期短一些讓舊Session盡快過期。更好的方案是代碼里做兼容處理讀數(shù)據(jù)失敗時catch異常并返回null讓Shiro對這個Session重新走創(chuàng)建流程。4.5 權(quán)限注解不生效的排查在Spring Boot項目里啟用Shiro注解需要確認兩個方面一是自定義Realm的Bean必須被Spring管理二是Shiro的注解掃描需要開啟。常見的配置是引入一個AuthorizationAttributeSourceAdvisor的Bean它的作用是把Shiro的注解和Spring AOP關(guān)聯(lián)起來。如果配置了還是不生效優(yōu)先檢查是不是類沒有被Spring掃描到或者接口方法用了private修飾。Shiro的注解是通過AOP代理實現(xiàn)的private方法是不會走代理的所以注解必須放在public方法上。5. 這個方案的擴展與優(yōu)化方向5.1 基于 Redis 的限流與防刷既然Redis已經(jīng)集成進來了順手加一個接口防刷的機制是很自然的擴展。在登錄接口上做限制比如同一個IP一分鐘內(nèi)最多嘗試5次登錄超過則直接拒絕。實現(xiàn)也不復雜用Redis的INCR和EXPIRE命令就能搞定。String key login:limit: ipAddress; Long count redisTemplate.opsForValue().increment(key); if (count ! null count 1) { redisTemplate.expire(key, 1, TimeUnit.MINUTES); } if (count ! null count 5) { throw new RuntimeException(登錄嘗試次數(shù)過多請稍后再試); }這個邏輯放在登錄接口的最前面攔截效果非常直接。它也是目前很多互聯(lián)網(wǎng)產(chǎn)品在用的登錄防暴力破解手段。5.2 記住我功能與退出策略Shiro自帶RememberMe功能開啟后用戶關(guān)閉瀏覽器SessionId仍然保存在本地Cookie中下次訪問自動恢復登錄狀態(tài)。Redis的引入讓RememberMe的實現(xiàn)更有優(yōu)勢因為Session數(shù)據(jù)在Redis里即使用戶換了節(jié)點只要Cookie中的SessionId還在依然能正確恢復登錄狀態(tài)。實現(xiàn)RememberMe需要在登錄時設(shè)置token的rememberMe屬性為true并在SecurityManager中配置一個rememberMeManager把Cookie的有效期調(diào)長。要注意的是RememberMe狀態(tài)下subject.isAuthenticated()為false但subject.isRemembered()為true。如果你的代碼里用isAuthenticated()做判斷未真正登錄就拒絕訪問的接口需要特別注意這個細節(jié)。5.3 集群環(huán)境下的多節(jié)點會話一致性這套方案在集群環(huán)境下的表現(xiàn)是比較理想的。因為所有Session數(shù)據(jù)都存在Redis每個節(jié)點讀到的都是同一份數(shù)據(jù)天然解決了會話一致性的問題。唯一要注意的是多個節(jié)點共享同一個Redis時序列化配置必須一致否則A節(jié)點寫入的數(shù)據(jù)會被B節(jié)點反序列化失敗。另一個要考慮的點是Redis的持久化策略要對齊公司的運維規(guī)范。如果Redis是純緩存模式、允許數(shù)據(jù)丟失那么Redis重啟后所有用戶會集體掉線必須重新登錄。如果希望高可用可以開啟Redis的持久化或者用主從模式哨兵。這塊屬于運維范疇但在方案設(shè)計階段就應(yīng)該想清楚免得后面上線時出大問題。6. 實操心得總結(jié)這套SpringBootShiroRedis的方案我從第一次接觸到今天前前后后在好幾個項目里落地過?；剡^頭來看最核心的收獲是技術(shù)選型一定要結(jié)合團隊的實際能力和項目的真實規(guī)模不要為了炫技去選一個用不上的框架。Shiro在中小型項目里依然是非常能打的方案搭配Redis之后的分布式會話能力完全夠用。而且它最大的優(yōu)勢在于概念直觀新同學上手速度快出現(xiàn)問題后定位路徑非常短。相比Spring Security同樣的功能在Shiro里的實現(xiàn)代碼量大概能少30%到40%這在項目周期緊的時候是實打?qū)嵉膬?yōu)勢。有一點我覺得值得養(yǎng)成習慣正式上線前一定要對認證授權(quán)模塊做一次專門的測試重點覆蓋Session過期、權(quán)限變更、多節(jié)點切換、并發(fā)登錄這幾個場景。這些邊角問題在單機開發(fā)和測試環(huán)境里很難暴露但一旦上了生產(chǎn)用戶報障的往往就是這類問題。最后再分享一個排查小技巧如果你在整合過程中碰到了詭異的Session、權(quán)限問題第一步永遠是去Redis里看看數(shù)據(jù)是什么樣的。數(shù)據(jù)在問題就在讀數(shù)據(jù)的環(huán)節(jié)數(shù)據(jù)不在問題就在寫數(shù)據(jù)的環(huán)節(jié)。這比反復看代碼猜原因高效得多。