1. 從一次登錄失效的排查說起為什么需要手動(dòng)操作Session最近在排查一個(gè)線上問題時(shí)遇到了一個(gè)挺典型的場景用戶反饋登錄后偶爾會(huì)莫名其妙地掉線需要重新登錄。排查日志發(fā)現(xiàn)用戶的Session在某個(gè)時(shí)間點(diǎn)被主動(dòng)清除了但業(yè)務(wù)代碼里并沒有顯式調(diào)用logout或invalidate。這讓我重新審視了項(xiàng)目中Shiro的Session管理機(jī)制。我們通常依賴Shiro的自動(dòng)管理比如登錄成功后自動(dòng)創(chuàng)建Session設(shè)置超時(shí)時(shí)間過期后自動(dòng)清理。但在一些復(fù)雜的業(yè)務(wù)流中比如強(qiáng)制用戶下線、踢人、會(huì)話數(shù)據(jù)遷移或者像我們遇到的這種“幽靈”失效問題僅僅依靠框架的默認(rèn)行為是不夠的。這時(shí)我們就需要主動(dòng)、精確地去“操作”Session。Shiro的Session API提供了一套比Servlet原生HttpSession更強(qiáng)大、更統(tǒng)一的操作接口。它抽象了底層細(xì)節(jié)讓你無論是在Web環(huán)境還是非Web環(huán)境比如單元測試、后臺(tái)任務(wù)都能用同一套方式管理用戶會(huì)話狀態(tài)。理解并熟練使用這些API意味著你能更好地控制應(yīng)用的安全狀態(tài)實(shí)現(xiàn)更精細(xì)化的用戶會(huì)話治理而不是被動(dòng)地處理各種因Session引發(fā)的詭異問題。接下來我就結(jié)合實(shí)戰(zhàn)拆解Shiro Session管理的核心操作。2. 理解Shiro Session的核心模型與關(guān)鍵接口在動(dòng)手寫代碼之前我們必須先搞清楚Shiro Session的“世界觀”。它并不是對HttpSession的簡單包裝而是一套自頂向下設(shè)計(jì)的、獨(dú)立的安全會(huì)話模型。2.1 Session會(huì)話數(shù)據(jù)的統(tǒng)一抽象接口org.apache.shiro.session.Session接口是Shiro會(huì)話管理的基石。你可以把它理解為一個(gè)鍵值對存儲(chǔ)專門用來存放與當(dāng)前交互用戶相關(guān)的數(shù)據(jù)。它與HttpSession最大的不同在于環(huán)境無關(guān)性。// 獲取當(dāng)前Subject的Session Session session SecurityUtils.getSubject().getSession(); // 存儲(chǔ)數(shù)據(jù) session.setAttribute(currentProjectId, 12345); // 獲取數(shù)據(jù) Integer projectId (Integer) session.getAttribute(currentProjectId); // 移除數(shù)據(jù) session.removeAttribute(currentProjectId);這里有一個(gè)關(guān)鍵細(xì)節(jié)getSession()方法有一個(gè)重載版本getSession(boolean create)。當(dāng)create為false時(shí)如果當(dāng)前沒有Session它會(huì)返回null。這在某些只讀檢查的場景下非常有用可以避免無意中創(chuàng)建一個(gè)不必要的Session。例如在統(tǒng)計(jì)在線用戶數(shù)時(shí)你只需要檢查是否存在有效的Session而不應(yīng)該為每個(gè)訪問者都創(chuàng)建一個(gè)。2.2 SessionManager會(huì)話生命周期的總指揮SessionManager負(fù)責(zé)Session的創(chuàng)建、維護(hù)和銷毀。在Web應(yīng)用中最常用的是DefaultWebSessionManager。它的配置決定了Session行為的方方面面。在Spring Boot的application.yml中典型的配置如下shiro: sessionManager: # Session全局超時(shí)時(shí)間毫秒默認(rèn)30分鐘 globalSessionTimeout: 1800000 # 是否開啟會(huì)話驗(yàn)證調(diào)度定期清理過期Session sessionValidationSchedulerEnabled: true # 會(huì)話驗(yàn)證調(diào)度器執(zhí)行間隔毫秒默認(rèn)1小時(shí) sessionValidationInterval: 3600000 # 是否在會(huì)話過期后刪除無效的Session ID Cookie deleteInvalidSessions: true # Session ID Cookie配置 sessionIdCookie: name: SHRIOSESSIONID httpOnly: true maxAge: -1 # 瀏覽器關(guān)閉即失效DefaultWebSessionManager的一個(gè)強(qiáng)大之處在于其會(huì)話驗(yàn)證機(jī)制。它內(nèi)部有一個(gè)SessionValidationScheduler默認(rèn)使用一個(gè)單線程的ExecutorService定期比如每小時(shí)一次掃描所有活躍的Session將那些lastAccessTime加上timeout已經(jīng)早于當(dāng)前時(shí)間的Session標(biāo)記為過期并清理。這就是為什么即使你不做任何操作閑置用戶也會(huì)自動(dòng)掉線的原因。注意在生產(chǎn)環(huán)境中如果應(yīng)用重啟內(nèi)存中的Session會(huì)全部丟失。DefaultWebSessionManager默認(rèn)將Session存儲(chǔ)在內(nèi)存中。對于需要持久化或集群部署的場景你需要配置SessionDAO例如使用EnterpriseCacheSessionDAO將會(huì)話數(shù)據(jù)存儲(chǔ)到Redis中。這時(shí)SessionManager和SessionDAO的協(xié)作就至關(guān)重要了。2.3 Subject與Session的綁定關(guān)系這是容易混淆的一點(diǎn)。我們通過SecurityUtils.getSubject().getSession()獲取的Session是與當(dāng)前Subject即當(dāng)前交互主體通常是用戶綁定的。在Web環(huán)境下Shiro會(huì)通過Cookie默認(rèn)名JSESSIONIDShiro可配置或URL參數(shù)找到Session ID然后從SessionManager中獲取對應(yīng)的Session對象再將其與當(dāng)前線程的Subject綁定。這意味著一個(gè)有效的Session可以沒有經(jīng)過認(rèn)證即用戶未登錄。例如用戶訪問網(wǎng)站首頁可能就已經(jīng)創(chuàng)建了一個(gè)匿名Session用于存放購物車信息或驗(yàn)證碼。只有當(dāng)調(diào)用subject.login(token)成功后這個(gè)Session才會(huì)與一個(gè)經(jīng)過認(rèn)證的身份Principal關(guān)聯(lián)起來。理解這一點(diǎn)對于后續(xù)實(shí)現(xiàn)“強(qiáng)制下線”等功能很重要——你操作的是SessionSession失效會(huì)導(dǎo)致綁定它的Subject也變?yōu)槲凑J(rèn)證狀態(tài)。3. 實(shí)戰(zhàn)Session的增刪改查與生命周期控制掌握了基本概念我們進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。下面這些操作是管理Session的日常。3.1 創(chuàng)建與獲取不僅僅是getSession()大多數(shù)情況下Session的創(chuàng)建是隱式的。當(dāng)?shù)谝淮握{(diào)用subject.getSession()或subject.getSession(true)時(shí)如果當(dāng)前沒有SessionSessionManager就會(huì)創(chuàng)建一個(gè)。但有些場景需要顯式控制。Subject currentUser SecurityUtils.getSubject(); // 方式1獲取現(xiàn)有Session不存在則創(chuàng)建最常用 Session session currentUser.getSession(); // 方式2僅獲取不存在則返回null用于檢查 Session existingSession currentUser.getSession(false); if (existingSession null) { log.info(當(dāng)前用戶沒有活躍會(huì)話可能是個(gè)新訪客。); // 可以在此處初始化一個(gè)匿名會(huì)話用于跟蹤 session currentUser.getSession(); session.setAttribute(visitTime, new Date()); }創(chuàng)建Session時(shí)一個(gè)重要的屬性是timeout超時(shí)時(shí)間毫秒。你可以在創(chuàng)建后單獨(dú)設(shè)置session.setTimeout(30 * 60 * 1000); // 設(shè)置為30分鐘但更常見的做法是在SessionManager級別配置globalSessionTimeout進(jìn)行統(tǒng)一管理。個(gè)人經(jīng)驗(yàn)是除非有非常特殊的、針對單個(gè)會(huì)話的超時(shí)需求比如付費(fèi)用戶會(huì)話時(shí)間更長否則盡量使用全局配置保持一致性減少維護(hù)復(fù)雜度。3.2 數(shù)據(jù)存取Attribute操作的最佳實(shí)踐向Session中存取數(shù)據(jù)看似簡單但有些細(xì)節(jié)能幫你避免坑。// 存數(shù)據(jù) session.setAttribute(key, value); // 取數(shù)據(jù) Object value session.getAttribute(key); // 刪數(shù)據(jù) session.removeAttribute(key); // 獲取所有Attribute的鍵 CollectionObject keys session.getAttributeKeys();實(shí)操心得一序列化問題如果你的應(yīng)用是集群部署并且使用了Redis等外部存儲(chǔ)作為SessionDAO的后端那么存入Session的所有對象必須實(shí)現(xiàn)java.io.Serializable接口。否則在序列化存儲(chǔ)時(shí)會(huì)拋出異常。這是一個(gè)非常常見的部署陷阱。建議在項(xiàng)目早期就建立規(guī)范規(guī)定所有可能放入Session的DTO或值對象都必須實(shí)現(xiàn)Serializable。實(shí)操心得二鍵的命名規(guī)范Session是全局的、基于字符串鍵的存儲(chǔ)容易發(fā)生鍵名沖突。特別是當(dāng)你引入第三方庫或框架它們也可能向Session中存放數(shù)據(jù)。一個(gè)良好的實(shí)踐是使用反向域名格式作為鍵的前綴例如com.yourcompany.project.module.key。這樣能最大程度避免沖突。實(shí)操心得三控制數(shù)據(jù)量Session數(shù)據(jù)通常存儲(chǔ)在服務(wù)器內(nèi)存或外部緩存中不宜存放過大或過多的數(shù)據(jù)。避免將整個(gè)用戶對象、大數(shù)據(jù)列表或文件流直接存入Session。只存放最小必要的標(biāo)識(shí)符和狀態(tài)信息比如用戶ID、角色列表、當(dāng)前租戶ID等。大對象可以考慮存入數(shù)據(jù)庫或分布式緩存在Session中只保留其引用ID。3.3 失效與登出理解invalidate()和logout()的區(qū)別這是兩個(gè)緊密相關(guān)但作用范圍不同的操作。session.invalidate()使當(dāng)前Session立即失效。調(diào)用后該Session對象將被標(biāo)記為無效并從SessionManager的存儲(chǔ)中移除。后續(xù)任何嘗試通過該Session ID訪問的操作都會(huì)失敗。但是它不會(huì)執(zhí)行Shiro的登出邏輯比如清理與Subject關(guān)聯(lián)的認(rèn)證信息Principal和授權(quán)信息Roles/Permissions。在單純的Web上下文中由于Session失效下次請求會(huì)因?yàn)闆]有Session ID而創(chuàng)建一個(gè)新的匿名Session用戶自然就“掉線”了。但這是一種比較“粗暴”的方式。subject.logout()這是Shiro提供的標(biāo)準(zhǔn)登出操作。它會(huì)做一系列清理工作調(diào)用session.invalidate()使會(huì)話失效。清除Subject中綁定的身份Principal和憑證Credential。清除線程上下文中與當(dāng)前Subject關(guān)聯(lián)的所有狀態(tài)。觸發(fā)登出事件監(jiān)聽器LogoutListener。// 場景用戶主動(dòng)點(diǎn)擊退出按鈕 RequestMapping(/logout) public String logout() { SecurityUtils.getSubject().logout(); // 重定向到登錄頁或首頁 return redirect:/login; } // 場景管理員在后臺(tái)強(qiáng)制讓某個(gè)用戶下線已知其Session ID public void forceLogout(String sessionId) { try { // 1. 通過SessionManager獲取到具體的Session對象 Session session sessionManager.retrieveSession(sessionId); if (session ! null) { // 2. 停止該會(huì)話 session.stop(); // 3. 顯式失效stop方法通常也會(huì)觸發(fā)失效但顯式調(diào)用更明確 session.invalidate(); log.info(已強(qiáng)制下線會(huì)話: {}, sessionId); } } catch (Exception e) { log.error(強(qiáng)制下線會(huì)話失敗: {}, sessionId, e); } }重要提示session.stop()方法來源于Session接口繼承的Stoppable接口。它主要用于釋放Session可能占用的資源然后通常會(huì)調(diào)用invalidate()。在強(qiáng)制下線時(shí)先stop()再invalidate()是一個(gè)更完整的流程。直接調(diào)用invalidate()在大多數(shù)情況下也夠用但遵循接口設(shè)計(jì)能更好地處理邊緣情況。那么在什么情況下用哪個(gè)用戶主動(dòng)退出永遠(yuǎn)使用subject.logout()。這是最規(guī)范、最安全的方式確保了所有安全狀態(tài)被正確清理。會(huì)話過期交給SessionManager的驗(yàn)證調(diào)度器自動(dòng)處理它會(huì)調(diào)用Session的expire()或invalidate()方法。管理員強(qiáng)制踢人如果你能拿到對應(yīng)用戶的Subject優(yōu)先用subject.logout()。如果只能拿到SessionId則通過SessionManager獲取Session后調(diào)用invalidate()。在這種情況下由于無法直接訪問目標(biāo)Subject的線程上下文logout()的某些清理動(dòng)作可能無法執(zhí)行但使Session失效足以達(dá)到踢人目的。3.4 監(jiān)聽會(huì)話事件讓管理更智能Shiro提供了SessionListener接口允許你在Session生命周期的關(guān)鍵節(jié)點(diǎn)插入自定義邏輯。這對于實(shí)現(xiàn)監(jiān)控、審計(jì)或特定業(yè)務(wù)聯(lián)動(dòng)非常有用。你需要實(shí)現(xiàn)這個(gè)接口并注冊到SessionManager中。Component public class CustomSessionListener implements SessionListener { Override public void onStart(Session session) { // 會(huì)話創(chuàng)建時(shí)觸發(fā)例如用戶首次訪問 String sessionId (String) session.getId(); log.info(會(huì)話啟動(dòng): ID{}, 開始時(shí)間{}, sessionId, session.getStartTimestamp()); // 可以在這里初始化一些會(huì)話級別的跟蹤信息 } Override public void onStop(Session session) { // 會(huì)話被顯式stop()時(shí)觸發(fā) log.info(會(huì)話停止: ID{}, session.getId()); } Override public void onExpiration(Session session) { // 會(huì)話過期時(shí)觸發(fā)超時(shí) String username (String) session.getAttribute(username); log.warn(會(huì)話過期: ID{}, 用戶{}, session.getId(), username); // 可以在這里觸發(fā)清理關(guān)聯(lián)資源的任務(wù)比如釋放用戶占用的臨時(shí)鎖 } }然后在Shiro的配置類中將其注入Bean public DefaultWebSessionManager sessionManager(CustomSessionListener customSessionListener) { DefaultWebSessionManager sessionManager new DefaultWebSessionManager(); // 設(shè)置其他配置... // 設(shè)置監(jiān)聽器集合 CollectionSessionListener listeners new ArrayList(); listeners.add(customSessionListener); sessionManager.setSessionListeners(listeners); return sessionManager; }一個(gè)實(shí)用的場景精準(zhǔn)的在線用戶統(tǒng)計(jì)。單純統(tǒng)計(jì)Session數(shù)量是不準(zhǔn)確的因?yàn)榘吹卿浀哪涿麜?huì)話。我們可以在用戶登錄成功的邏輯里向他的Session中存入一個(gè)標(biāo)識(shí)如session.setAttribute(loggedIn, true)。然后在onExpiration和onStop監(jiān)聽器中檢查這個(gè)標(biāo)識(shí)如果是已登錄用戶的會(huì)話失效就更新在線用戶計(jì)數(shù)。這樣得到的數(shù)據(jù)遠(yuǎn)比簡單的Session計(jì)數(shù)有價(jià)值。4. 進(jìn)階場景基于SessionManager的精細(xì)化管控當(dāng)我們不滿足于對當(dāng)前用戶Session的操作而是需要從系統(tǒng)層面查看和管理所有活躍會(huì)話時(shí)就需要直接與SessionManager打交道了。4.1 檢索與遍歷所有活躍會(huì)話SessionManager具體是其底層的SessionDAO提供了獲取活躍會(huì)話的方法。這在實(shí)現(xiàn)“在線用戶列表”或“會(huì)話管理”后臺(tái)功能時(shí)是核心API。Autowired private SessionManager sessionManager; /** * 獲取所有活躍會(huì)話注意性能敏感操作謹(jǐn)慎使用 */ public CollectionSession getActiveSessions() { // 需要將SessionManager轉(zhuǎn)型為具體的實(shí)現(xiàn)類以調(diào)用getActiveSessions方法 // 注意DefaultWebSessionManager本身沒有這個(gè)方法方法在其父類AbstractNativeSessionManager中 // 更通用的方式是注入SessionDAO if (sessionManager instanceof AbstractNativeSessionManager) { // 這種方式依賴于Shiro內(nèi)部API可能在不同版本間有變化 return ((AbstractNativeSessionManager) sessionManager).getActiveSessions(); } // 更推薦的方式直接注入并使用SessionDAO return Collections.emptyList(); } // 更佳實(shí)踐直接操作SessionDAO Autowired(required false) // requiredfalse防止沒有配置SessionDAO時(shí)啟動(dòng)失敗 private SessionDAO sessionDAO; public ListMapString, Object getActiveSessionList() { ListMapString, Object sessionList new ArrayList(); if (sessionDAO ! null) { // 獲取所有活躍會(huì)話的鍵通常是Session ID CollectionSession sessions sessionDAO.getActiveSessions(); for (Session session : sessions) { MapString, Object sessionInfo new HashMap(); sessionInfo.put(sessionId, session.getId()); sessionInfo.put(startTime, session.getStartTimestamp()); sessionInfo.put(lastAccessTime, session.getLastAccessTime()); sessionInfo.put(timeout, session.getTimeout()); sessionInfo.put(host, session.getHost()); // 用戶IP // 獲取登錄用戶信息如果已登錄 String username (String) session.getAttribute(username); sessionInfo.put(username, username ! null ? username : 匿名訪客); sessionList.add(sessionInfo); } } return sessionList; }警告getActiveSessions()操作在會(huì)話數(shù)量很大時(shí)比如上萬可能會(huì)對性能尤其是內(nèi)存和CPU造成顯著影響因?yàn)樗赡苄枰獜拇鎯?chǔ)中加載大量數(shù)據(jù)。絕對不要在頻繁調(diào)用的接口如每次頁面請求中使用此方法。它只適用于管理員偶爾查看的后臺(tái)功能。對于大規(guī)模應(yīng)用應(yīng)考慮分頁查詢或使用專門的監(jiān)控系統(tǒng)。4.2 實(shí)現(xiàn)強(qiáng)制下線踢人功能這是后臺(tái)管理系統(tǒng)的常見需求。原理就是通過目標(biāo)用戶的Session ID找到對應(yīng)的Session并使其失效。Service public class SessionManagementService { Autowired private SessionDAO sessionDAO; /** * 根據(jù)用戶名強(qiáng)制下線假設(shè)用戶名已存入Session的username屬性 * param username 要下線的用戶名 * return 被下線的會(huì)話數(shù)量 */ public int forceLogoutByUsername(String username) { int count 0; CollectionSession sessions sessionDAO.getActiveSessions(); for (Session session : sessions) { // 遍歷所有會(huì)話找到對應(yīng)用戶的會(huì)話 String sessionUser (String) session.getAttribute(username); if (username.equals(sessionUser)) { try { // 使會(huì)話失效 session.stop(); sessionDAO.delete(session); count; log.info(已強(qiáng)制下線用戶[{}]的會(huì)話: {}, username, session.getId()); } catch (Exception e) { log.error(下線用戶[{}]會(huì)話失敗: {}, username, session.getId(), e); } } } return count; } /** * 根據(jù)Session ID強(qiáng)制下線 * param sessionId 會(huì)話ID * return 是否成功 */ public boolean forceLogoutBySessionId(String sessionId) { try { Session session sessionDAO.readSession(sessionId); if (session ! null) { session.stop(); sessionDAO.delete(session); log.info(已強(qiáng)制下線會(huì)話: {}, sessionId); return true; } } catch (Exception e) { log.error(下線會(huì)話失敗: {}, sessionId, e); } return false; } }關(guān)鍵點(diǎn)與避坑指南并發(fā)問題在遍歷getActiveSessions()并執(zhí)行刪除操作時(shí)如果會(huì)話集合非常大操作期間可能有新的會(huì)話創(chuàng)建或舊的會(huì)話過期。ConcurrentModificationException是潛在風(fēng)險(xiǎn)。一種更穩(wěn)健的做法是先收集需要?jiǎng)h除的Session ID列表然后再遍歷這個(gè)列表逐個(gè)刪除。通知客戶端調(diào)用session.invalidate()或delete()只會(huì)使服務(wù)器端的Session失效。用戶客戶端的瀏覽器仍然持有舊的Session ID Cookie在下次請求前他可能感知不到自己已被踢出。對于追求實(shí)時(shí)體驗(yàn)的應(yīng)用可以在踢人后通過WebSocket或Server-Sent Events (SSE) 主動(dòng)通知客戶端“賬號(hào)已在別處登錄”引導(dǎo)其刷新頁面或跳轉(zhuǎn)到登錄頁。資源清理確保SessionListener.onExpiration或onStop中的邏輯能正確處理這種強(qiáng)制失效的情況及時(shí)清理與該會(huì)話關(guān)聯(lián)的臨時(shí)文件、數(shù)據(jù)庫鎖等資源。4.3 自定義Session ID生成與Cookie管理默認(rèn)情況下Shiro使用JavaUuidSessionIdGenerator生成隨機(jī)的UUID作為Session ID。Cookie則通過SimpleCookie來管理。有時(shí)我們需要定制它們。場景一定制Session ID生成器。比如出于安全審計(jì)要求需要在Session ID中嵌入部分可讀信息注意不能包含敏感信息。public class CustomSessionIdGenerator implements SessionIdGenerator { Override public Serializable generateId(Session session) { // 生成一個(gè)前綴UUID的組合ID例如 WEB_3f19c83f-... String prefix WEB_; return prefix java.util.UUID.randomUUID().toString(); } } // 在配置中設(shè)置 sessionManager.setSessionIdGenerator(new CustomSessionIdGenerator());場景二精細(xì)化Cookie配置。應(yīng)對安全掃描設(shè)置更嚴(yán)格的Cookie屬性。Bean public DefaultWebSessionManager sessionManager() { DefaultWebSessionManager sessionManager new DefaultWebSessionManager(); // 禁用URL重寫傳遞Session ID更安全 sessionManager.setSessionIdUrlRewritingEnabled(false); SimpleCookie sessionIdCookie new SimpleCookie(SHRIOSESSIONID); sessionIdCookie.setHttpOnly(true); // 防止XSS讀取Cookie sessionIdCookie.setSecure(true); // 僅HTTPS傳輸生產(chǎn)環(huán)境務(wù)必開啟 sessionIdCookie.setMaxAge(-1); // 瀏覽器會(huì)話結(jié)束時(shí)過期 sessionIdCookie.setPath(/); // Cookie路徑 // 設(shè)置SameSite屬性以防范CSRF (需要Shiro 1.6或通過Servlet容器配置) // sessionIdCookie.setSameSite(Lax); sessionManager.setSessionIdCookie(sessionIdCookie); sessionManager.setSessionIdCookieEnabled(true); return sessionManager; }安全提醒Secure和HttpOnly是保護(hù)Session Cookie的關(guān)鍵標(biāo)志。Secure確保Cookie只通過加密的HTTPS連接傳輸防止中間人竊聽。HttpOnly阻止JavaScript通過document.cookie訪問此Cookie能有效緩解XSS攻擊竊取會(huì)話的風(fēng)險(xiǎn)。在生產(chǎn)環(huán)境中這兩項(xiàng)應(yīng)該始終啟用。5. 集群環(huán)境下的Session管理從內(nèi)存到Redis單機(jī)應(yīng)用的內(nèi)存Session管理很簡單但一旦涉及多實(shí)例部署集群就必須解決Session共享問題。否則用戶請求被負(fù)載均衡到不同服務(wù)器會(huì)因找不到之前的Session而導(dǎo)致登錄狀態(tài)丟失。Shiro通過SessionDAO抽象了Session的持久化層。默認(rèn)的MemorySessionDAO只存內(nèi)存。我們需要將其替換為支持分布式存儲(chǔ)的DAO最常用的是基于Redis的實(shí)現(xiàn)。5.1 集成Redis作為Session存儲(chǔ)首先引入Shiro Redis集成的依賴以Spring Boot為例dependency groupIdorg.crazycake/groupId artifactIdshiro-redis/artifactId version3.3.1/version !-- 注意版本與Shiro、Spring Boot兼容性 -- /dependency然后進(jìn)行配置Configuration public class ShiroConfig { Bean public RedisManager redisManager() { RedisManager redisManager new RedisManager(); redisManager.setHost(localhost:6379); // 可設(shè)置密碼、超時(shí)、數(shù)據(jù)庫索引等 // redisManager.setPassword(yourpassword); // redisManager.setTimeout(2000); // redisManager.setDatabase(0); return redisManager; } Bean public RedisSessionDAO redisSessionDAO(RedisManager redisManager) { RedisSessionDAO sessionDAO new RedisSessionDAO(); sessionDAO.setRedisManager(redisManager); // 設(shè)置Session在Redis中的key前綴 sessionDAO.setKeyPrefix(shiro:session:); // 設(shè)置Session過期時(shí)間毫秒這里設(shè)置為與全局超時(shí)一致 sessionDAO.setExpire(1800000); return sessionDAO; } Bean public DefaultWebSessionManager sessionManager(RedisSessionDAO redisSessionDAO) { DefaultWebSessionManager sessionManager new DefaultWebSessionManager(); // 禁用Servlet容器的Session管理 sessionManager.setSessionIdUrlRewritingEnabled(false); sessionManager.setSessionValidationSchedulerEnabled(true); sessionManager.setGlobalSessionTimeout(1800000); // 使用RedisSessionDAO sessionManager.setSessionDAO(redisSessionDAO); return sessionManager; } }5.2 集群環(huán)境下的注意事項(xiàng)序列化再次強(qiáng)調(diào)所有存入Session的Attribute對象必須實(shí)現(xiàn)Serializable。shiro-redis默認(rèn)使用JdkSerializationRedisSerializer要求很嚴(yán)格。你也可以配置為Jackson2JsonRedisSerializer等但要注意類路徑一致性問題。Session過期同步Redis本身支持鍵過期。shiro-redis會(huì)在創(chuàng)建Session時(shí)設(shè)置一個(gè)Redis TTL生存時(shí)間。Shiro的SessionValidationScheduler會(huì)話驗(yàn)證調(diào)度器在集群環(huán)境下仍然會(huì)運(yùn)行但它主要是為了調(diào)用SessionDAO的delete方法清理已過期的Session實(shí)體并觸發(fā)SessionListener.onExpiration事件。Redis的自動(dòng)過期是另一道保障。建議將Shiro的sessionValidationInterval設(shè)置得比Session超時(shí)時(shí)間短一些例如Session超時(shí)30分鐘驗(yàn)證間隔20分鐘以確保監(jiān)聽器邏輯能被及時(shí)觸發(fā)。強(qiáng)制下線功能的調(diào)整在集群中forceLogoutByUsername的實(shí)現(xiàn)需要遍歷所有Redis中的Session。shiro-redis的getActiveSessions()方法默認(rèn)會(huì)返回Redis中所有前綴匹配的Session。在大規(guī)模集群中這個(gè)操作可能非常慢且消耗資源。生產(chǎn)環(huán)境應(yīng)考慮其他方案方案A推薦在用戶登錄時(shí)將其Session ID與用戶ID的映射關(guān)系額外存儲(chǔ)到一個(gè)Redis Hash或Set中。踢人時(shí)先從這個(gè)映射中快速找到對應(yīng)用戶的所有Session ID再進(jìn)行精準(zhǔn)刪除。這需要維護(hù)額外的數(shù)據(jù)結(jié)構(gòu)。方案B使用Redis的Keyspace通知Key Events。配置Redis在鍵Session過期或被刪除時(shí)發(fā)布通知應(yīng)用監(jiān)聽這些通知來執(zhí)行資源清理等后續(xù)操作而不是主動(dòng)去遍歷查詢。網(wǎng)絡(luò)與性能Session的每次讀寫都變成了網(wǎng)絡(luò)IO對Redis的延遲和可用性要求很高。確保Redis是高可用的主從、集群模式并且應(yīng)用服務(wù)器與Redis之間的網(wǎng)絡(luò)延遲要低?？梢钥紤]使用連接池shiro-redis已支持和合理的超時(shí)設(shè)置。6. 排查與調(diào)試Session不聽話時(shí)的工具箱即使理解了所有原理實(shí)戰(zhàn)中Session依然可能表現(xiàn)出各種“詭異”行為。下面分享幾個(gè)排查思路和工具。6.1 常見問題與排查路徑問題一登錄后Session丟失頻繁要求重新登錄。排查點(diǎn)1Cookie路徑與域名。檢查瀏覽器開發(fā)者工具中的Application - Cookies。確認(rèn)Session Cookie的Domain和Path是否正確。例如如果你的應(yīng)用部署在https://app.example.com但Cookie的Domain是.example.com這是正確的子域名共享。如果Path是/admin那么只有/admin下的請求會(huì)攜帶Cookie其他路徑的請求就會(huì)丟失Session。排查點(diǎn)2Secure標(biāo)志。如果你的網(wǎng)站使用了HTTPS但Cookie沒有設(shè)置Securetrue有些瀏覽器如Chrome新版本可能會(huì)拒絕發(fā)送這個(gè)Cookie。排查點(diǎn)3跨域問題。如果前端https://ui.example.com和后端APIhttps://api.example.com域名不同屬于跨域。默認(rèn)情況下Cookie不會(huì)自動(dòng)攜帶。需要在服務(wù)端設(shè)置Cookie時(shí)指定SameSiteNone; Secure并且前端請求需要設(shè)置withCredentials: true。同時(shí)服務(wù)端響應(yīng)頭需要包含Access-Control-Allow-Credentials: true和正確的Access-Control-Allow-Origin不能是*。排查點(diǎn)4Session超時(shí)時(shí)間過短。檢查globalSessionTimeout配置確認(rèn)是否設(shè)置得太小比如幾分鐘。排查點(diǎn)5集群環(huán)境Session未同步。確認(rèn)請求是否被負(fù)載均衡到了不同實(shí)例以及Redis等共享存儲(chǔ)是否工作正常。檢查Redis中是否存在對應(yīng)的Session鍵。問題二getActiveSessions()返回空或數(shù)量不對。排查點(diǎn)1SessionDAO是否正確注入。在非Web環(huán)境或特定配置下SessionDAO可能沒有被正確設(shè)置到SessionManager中。打印sessionManager.getSessionDAO()的類名確認(rèn)。排查點(diǎn)2Redis連接與序列化。對于Redis存儲(chǔ)檢查Redis連接是否正常以及存儲(chǔ)的鍵前綴keyPrefix是否匹配。使用Redis客戶端工具如redis-cli直接查看keys shiro:session:*看數(shù)據(jù)是否存在以及序列化格式是否正確。排查點(diǎn)3權(quán)限問題。getActiveSessions()方法可能需要特定的權(quán)限才能調(diào)用檢查調(diào)用者是否有相應(yīng)授權(quán)。6.2 利用監(jiān)聽器和日志進(jìn)行調(diào)試給SessionDAO和SessionManager增加詳細(xì)的日志級別輸出是追蹤Session生命周期的有效手段。在logback-spring.xml中增加配置logger nameorg.apache.shiro.session.mgt levelDEBUG/ logger nameorg.apache.shiro.session.dao levelDEBUG/ !-- 如果用了shiro-redis -- logger nameorg.crazycake.shiro levelDEBUG/這樣你就能在日志中看到Session的創(chuàng)建doCreate、讀取doReadSession、更新doUpdate、刪除doDelete以及過期驗(yàn)證等詳細(xì)過程。結(jié)合之前編寫的CustomSessionListener在onStart、onStop、onExpiration方法中加入詳細(xì)的日志輸出可以清晰地描繪出一個(gè)會(huì)話從生到死的完整軌跡對于定位“幽靈”失效問題尤其有幫助。6.3 一個(gè)真實(shí)的踩坑案例StopedSessionException有一次線上報(bào)警大量用戶出現(xiàn)StopedSessionException。這個(gè)異常表示程序試圖訪問一個(gè)已經(jīng)被標(biāo)記為停止stopped的Session。排查發(fā)現(xiàn)問題出在一個(gè)自定義的Filter中。這個(gè)Filter的邏輯是檢查某個(gè)請求參數(shù)如果參數(shù)不合法就直接重定向到錯(cuò)誤頁。問題在于它在重定向前先調(diào)用了一次subject.getSession()來記錄日志。而在某些異常處理流程中Shiro可能會(huì)先使當(dāng)前Session失效stop然后才走到這個(gè)Filter。此時(shí)getSession()會(huì)嘗試獲取一個(gè)已停止的Session從而拋出異常。修復(fù)方案在Filter中將subject.getSession()改為subject.getSession(false)如果返回null則說明Session已無效不再進(jìn)行記錄操作?；蛘邔⑷罩居涗浀倪壿嬕频礁壳暗?、Session肯定有效的Filter中。這個(gè)坑的教訓(xùn)是在異常處理或重定向的邏輯分支中要謹(jǐn)慎操作Session優(yōu)先使用getSession(false)進(jìn)行空值判斷避免對無效Session進(jìn)行操作。操作Shiro Session從基本的存取刪改到進(jìn)階的全局管理和集群部署每一步都需要對框架機(jī)制有清晰的理解。它不僅僅是調(diào)用幾個(gè)API那么簡單更關(guān)乎應(yīng)用的狀態(tài)一致性、安全性和用戶體驗(yàn)。尤其是在微服務(wù)和分布式架構(gòu)成為主流的今天將會(huì)話狀態(tài)無狀態(tài)化如采用JWT是另一個(gè)趨勢但理解傳統(tǒng)的、有狀態(tài)的Session管理仍然是構(gòu)建穩(wěn)健后臺(tái)系統(tǒng)的重要基石。