Spring Session、Spring Security 和 Redis 這套組合拳是分布式場(chǎng)景下繞不開的標(biāo)配。很多團(tuán)隊(duì)做到集群部署這一步第一道坎就是登錄狀態(tài)失效明明在 A 服務(wù)器登錄了請(qǐng)求一打到 B 服務(wù)器就被踢回登錄頁(yè)。解決思路很多主流方案就是讓 Session 不再躺在各自的 Tomcat 內(nèi)存里而是統(tǒng)一丟到 Redis配合 Spring Security 做認(rèn)證授權(quán)再把會(huì)話數(shù)據(jù)無(wú)狀態(tài)化地共享出去。這篇文章我把自己的經(jīng)驗(yàn)梳理一遍從依賴引入開始到配置類和過濾器鏈的整合原理再到實(shí)際跑通驗(yàn)證最后把 Redis 里存的到底是什么、序列化方案怎么選這類細(xì)節(jié)也講透。這次就用最簡(jiǎn)單直白的方式呈現(xiàn)適合剛接觸會(huì)話共享、卡在 Spring Security 和 Redis 整合這一步的 Java 后端開發(fā)者看完可以直接抄作業(yè)也搞清楚背后每條配置的取舍邏輯。1. 整合前必須想明白的三個(gè)問題1.1 不做會(huì)話共享分布式部署會(huì)踩什么坑得先理解問題本身。傳統(tǒng)單機(jī)部署時(shí)用戶登錄之后服務(wù)器把 Session 保存在自己的內(nèi)存里再通過 Cookie 里的 JSESSIONID 與用戶一一對(duì)應(yīng)。同一個(gè)瀏覽器始終訪問同一臺(tái)服務(wù)器一切都很和諧。但一旦上 Nginx 做負(fù)載均衡流量被分發(fā)到多個(gè)節(jié)點(diǎn)問題就來了。用戶第一次請(qǐng)求落在節(jié)點(diǎn) ASession 也建在節(jié)點(diǎn) A下一次請(qǐng)求被 Nginx 轉(zhuǎn)發(fā)到節(jié)點(diǎn) B節(jié)點(diǎn) B 的內(nèi)存里根本沒有這個(gè) Session于是被判定為未登錄。這就是經(jīng)典的 Session 不一致問題很多人第一次遇到時(shí)以為是 Security 配置寫錯(cuò)了折騰半天才發(fā)現(xiàn)是會(huì)話存儲(chǔ)的位置出了問題。解決方案無(wú)非三種Nginx 配置 IP Hash讓同一個(gè) IP 固定打到同一臺(tái)節(jié)點(diǎn)治標(biāo)不治本移動(dòng)網(wǎng)絡(luò)下 IP 變化照樣失效節(jié)點(diǎn)宕機(jī)遷移時(shí)也照樣丟狀態(tài)。Tomcat 集群會(huì)話復(fù)制節(jié)點(diǎn)之間同步 Session實(shí)現(xiàn)簡(jiǎn)單但廣播風(fēng)暴嚴(yán)重節(jié)點(diǎn)一多性能雪崩。把 Session 集中存到 Redis所有節(jié)點(diǎn)共用同一個(gè)存儲(chǔ)層這是目前最主流、最推薦的做法也是 Spring Session 的核心價(jià)值所在。1.2 Spring Session 在這套架構(gòu)里扮演什么角色Spring Session 不是一個(gè)獨(dú)立運(yùn)行的中間件它本質(zhì)上是 Servlet 容器與 Redis 之間的一層橋接。它通過一個(gè) Filter 攔截所有請(qǐng)求把原本由 Tomcat 管理的 HttpSession 替換成 RedisSession底層讀寫全部走 Redis對(duì)業(yè)務(wù)代碼完全透明。這層替換的核心動(dòng)作有兩個(gè)請(qǐng)求進(jìn)來時(shí)從 Cookie 讀出 SessionId拿這個(gè) Key 去 Redis 查數(shù)據(jù)查到就恢復(fù)成完整的 Session 對(duì)象。響應(yīng)返回時(shí)把 Session 的變化寫回 Redis同時(shí)更新過期時(shí)間并把 SessionId 通過 Cookie 返回給瀏覽器。整個(gè)過程對(duì)應(yīng)用無(wú)感知業(yè)務(wù)代碼里 request.getSession() 拿到的是同一個(gè)接口但背后存儲(chǔ)已經(jīng)從本地內(nèi)存切換到了 Redis。這就是 Spring Session 的獨(dú)特價(jià)值不需要改業(yè)務(wù)代碼只需要引入依賴和配置就完成了會(huì)話存儲(chǔ)的搬遷。1.3 Spring Security 與 Session 到底誰(shuí)依賴誰(shuí)這個(gè)點(diǎn)很多人其實(shí)沒理清。Spring Security 本身并不一定需要 Session它基于過濾器鏈做認(rèn)證和授權(quán)但框架默認(rèn)會(huì)把認(rèn)證成功的 SecurityContext 存進(jìn) Session通過 session id 在后續(xù)請(qǐng)求中恢復(fù)上下文。具體來看SecurityContextPersistenceFilter 這個(gè)過濾器負(fù)責(zé)在請(qǐng)求開始時(shí)從 Session 中取出 SecurityContext放到 ThreadLocal 里請(qǐng)求結(jié)束后再把 ThreadLocal 里的 SecurityContext 寫回 Session。如果 Session 存到 Redis那么這個(gè)讀寫操作的存儲(chǔ)介質(zhì)也就自然變成了 Redis。所以整合邏輯就通了Spring Security 負(fù)責(zé)認(rèn)證Spring Session 負(fù)責(zé)把認(rèn)證結(jié)果存到 RedisRedis 是整個(gè)會(huì)話數(shù)據(jù)的統(tǒng)一載體。三者的關(guān)系不是堆疊而是各司其職的協(xié)作。2. 依賴引入與基礎(chǔ)配置2.1 Maven 依賴清單用 Spring Boot 的話整合工作極大簡(jiǎn)化我用的版本是 Spring Boot 2.7.x依賴如下dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.session/groupId artifactIdspring-session-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.apache.commons/groupId artifactIdcommons-pool2/artifactId /dependency /dependencies這幾個(gè)依賴要注意幾點(diǎn)spring-session-data-redis 是核心負(fù)責(zé)把 Session 存儲(chǔ)到 Redis。spring-boot-starter-data-redis 提供 Redis 連接管理兩者需要同時(shí)引入。commons-pool2 是 Lettuce 連接池所需不加的話如果配置了連接池參數(shù)會(huì)啟動(dòng)報(bào)錯(cuò)。Spring Boot 3.x 的用法有差異Spring Security 配置改用 Lambda DSLSpring Session 也需要額外引入 spring-session-core這里不展開我用 2.7.x 做演示生產(chǎn)項(xiàng)目用 3.x 的可以參照官方遷移文檔做適配。2.2 YAML 配置里最容易忽略的細(xì)節(jié)配置文件和普通 Redis 項(xiàng)目沒有太大區(qū)別重點(diǎn)是幾個(gè)容易被忽略的參數(shù)spring: redis: host: 127.0.0.1 port: 6379 password: database: 0 timeout: 5s lettuce: pool: max-active: 8 max-idle: 8 min-idle: 0 max-wait: -1ms session: store-type: redis timeout: 30mspring.session.store-typeredis 是核心開關(guān)告訴 Spring Boot 使用 Redis 作為 Session 存儲(chǔ)同時(shí)自動(dòng)配置 SessionRepositoryFilter。spring.session.timeout30m 是 Session 過期時(shí)間注意它和 server.servlet.session.timeout 的優(yōu)先級(jí)關(guān)系。兩者都存在時(shí)spring.session.timeout 優(yōu)先生效。如果沒配置默認(rèn)是 30 分鐘。Redis 的 database 必須統(tǒng)一。如果同一個(gè) Redis 實(shí)例被多個(gè)項(xiàng)目共用建議給不同項(xiàng)目分不同 database或者用不同 key 前綴區(qū)分。Spring Session 默認(rèn)的 key 前綴是 spring:session多個(gè)項(xiàng)目共用一個(gè) Redis 時(shí)需要覆蓋默認(rèn)的 RedisIndexedSessionRepository 或 RedisSessionRepository 的 key 命名規(guī)則否則不同項(xiàng)目的 Session 會(huì)互相污染。2.3 Redis 連接配置的三個(gè)參數(shù)心得host 和 port 沒什么好說的有幾個(gè)參數(shù)是生產(chǎn)環(huán)境必須考慮的timeout 建議設(shè)置 3-5 秒避免 Redis 阻塞時(shí)線程無(wú)限等待拖垮整個(gè)應(yīng)用。lettuce.pool.max-active 控制連接池最大連接數(shù)默認(rèn) 8壓測(cè)時(shí)如果發(fā)現(xiàn)連接不夠可以通過 Redis 的 INFO clients 命令查看實(shí)際連接情況再調(diào)整。max-wait 不建議設(shè)成 -1無(wú)限等待改成 3000ms 左右的有限等待Redis 抖動(dòng)時(shí)不會(huì)把線程全部耗盡。很多初學(xué)者踩過的坑是只寫了 host 和 port連接池參數(shù)完全沒配一旦業(yè)務(wù)流量上來Lettuce 的默認(rèn)連接數(shù)不夠用日志里出現(xiàn) connection pool exhausted 的異常。這個(gè)問題不致命但排查起來比較費(fèi)勁。3. Spring Security 配置核心類3.1 安全配置類的寫法引入依賴之后Spring Boot 會(huì)自動(dòng)生成一個(gè)默認(rèn)的 Security 配置會(huì)彈出一個(gè)默認(rèn)的登錄頁(yè)并且默認(rèn)用戶名是 user。我們要替換成自己的配置類Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .antMatchers(/login, /logout, /public/**).permitAll() .antMatchers(/admin/**).hasRole(ADMIN) .anyRequest().authenticated() ) .formLogin(form - form .loginPage(/login) .loginProcessingUrl(/login) .defaultSuccessUrl(/index, true) .permitAll() ) .logout(logout - logout .logoutUrl(/logout) .deleteCookies(JSESSIONID) .invalidateHttpSession(true) ) .csrf(csrf - csrf.disable()) .sessionManagement(session - session .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) .maximumSessions(5) .maxSessionsPreventsLogin(false) ); return http.build(); } }幾個(gè)關(guān)鍵點(diǎn)usernameParameter 和 passwordParameter 默認(rèn)是 username 和 password如果登錄請(qǐng)求參數(shù)名不一樣需要在 formLogin 配置里指定。loginPage 指定的是自定義登錄頁(yè)如果項(xiàng)目里有對(duì)應(yīng)的頁(yè)面就填頁(yè)面路徑?jīng)]有的話可以用 /login 讓 Spring Security 渲染默認(rèn)頁(yè)面。csrf.disable() 這個(gè)操作我平時(shí)只在開發(fā)環(huán)境或者純 API 接口項(xiàng)目里做有頁(yè)面交互的項(xiàng)目強(qiáng)烈建議保留 CSRF 防護(hù)具體原因后面單獨(dú)說。maximumSessions(5) 表示同一個(gè)用戶最多允許 5 個(gè)會(huì)話同時(shí)在線超過時(shí)舊會(huì)話會(huì)被踢下線這個(gè)參數(shù)要結(jié)合業(yè)務(wù)場(chǎng)景考慮太嚴(yán)會(huì)影響正常多端登錄。3.2 UserDetailsService 的用戶加載邏輯默認(rèn)配置是使用內(nèi)存用戶真實(shí)項(xiàng)目必須換成數(shù)據(jù)庫(kù)或其他存儲(chǔ)。最直接的方式是實(shí)現(xiàn) UserDetailsServiceService public class UserDetailsServiceImpl implements UserDetailsService { Autowired private UserMapper userMapper; Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { UserDO user userMapper.findByUsername(username); if (user null) { throw new UsernameNotFoundException(用戶不存在); } return org.springframework.security.core.userdetails.User .builder() .username(user.getUsername()) .password(user.getPassword()) .roles(ADMIN, USER) .build(); } }這里有一個(gè)常見困惑為什么登錄時(shí)只是傳了用戶名和密碼最后卻要把完整的權(quán)限和角色都交給 Security因?yàn)檎J(rèn)證成功后SecurityContext 里保存的就是這個(gè) UserDetails 對(duì)象后續(xù)每次請(qǐng)求從 Session 恢復(fù)出來的也是它。如果角色在這里面缺失后面做方法級(jí)權(quán)限校驗(yàn)PreAuthorize就會(huì)直接失敗。還有一個(gè)細(xì)節(jié)PasswordEncoder 必須和數(shù)據(jù)庫(kù)里的密碼加密方式一致。如果數(shù)據(jù)庫(kù)里存的是 BCrypt 加密的密文那么 PasswordEncoder 必須對(duì)應(yīng)配置Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }如果密碼是明文存的可以臨時(shí)用 NoOpPasswordEncoder但生產(chǎn)環(huán)境千萬(wàn)不要這樣做明文密碼在任何正規(guī)項(xiàng)目里都是紅線。3.3 SecurityContext 是怎么進(jìn)到 Session 的這塊講透的話后面排查問題會(huì)少走很多彎路。用戶提交登錄請(qǐng)求后UsernamePasswordAuthenticationFilter 攔截到請(qǐng)求調(diào)用 AuthenticationManager 做認(rèn)證認(rèn)證成功后拿著 Authentication 對(duì)象創(chuàng)建一個(gè) SecurityContext然后把它塞進(jìn) HttpSession 里。這個(gè)塞入動(dòng)作發(fā)生在 SecurityContextPersistenceFilter 的最后階段。每個(gè)請(qǐng)求進(jìn)來時(shí)它會(huì)先檢查當(dāng)前 Session 里有沒有 SecurityContext有就恢復(fù)到當(dāng)前線程請(qǐng)求結(jié)束時(shí)如果 SecurityContext 變化了就再寫回 Session。所以答案很清晰Spring Security 不直接操作 Redis它操作的是 HttpSession 這個(gè)抽象層Spring Session 把這個(gè)抽象層搬到了 Redis。這也解釋了為什么 Spring Security 配置本身和 Redis 沒有直接整合關(guān)系整合的關(guān)鍵在中間層。4. Spring Session 的工作機(jī)制與 Redis 底層數(shù)據(jù)4.1 SessionRepositoryFilter 過濾器如何接管會(huì)話Spring Session 的核心是一個(gè)名叫 SessionRepositoryFilter 的過濾器它的優(yōu)先級(jí)最高在 Spring Security 的過濾器鏈之前執(zhí)行。它的工作流程請(qǐng)求進(jìn)來時(shí)包裝原始的 HttpServletRequest把 getSession() 方法的實(shí)現(xiàn)替換為從 RedisSessionRepository 讀取 Session。請(qǐng)求放行給下游過濾器包括 Spring Security 的過濾器鏈處理。請(qǐng)求結(jié)束后將 Session 的變更同步到 Redis同時(shí)寫 Cookie 響應(yīng)給瀏覽器。這個(gè)過濾器的優(yōu)先級(jí)決定了它不能被隨意替換或跳過。如果項(xiàng)目里自定義了優(yōu)先級(jí)特別高的過濾器要小心是否會(huì)干擾 Session 的恢復(fù)尤其是那些依賴 session 做業(yè)務(wù)初始化的過濾器最好在 Session 恢復(fù)之后執(zhí)行。4.2 Redis 里 Session 的實(shí)際保存形式實(shí)現(xiàn)層面Spring Boot 2.7.x 默認(rèn)配置 RedisSessionRepository舊版是 RedisIndexedSessionRepository它會(huì)為每個(gè) Session 生成一組 Hash 結(jié)構(gòu)spring:session:sessions:1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed這里的 key 是 SessionIdHash 里保存的字段包括creationTime創(chuàng)建時(shí)間lastAccessedTime最后訪問時(shí)間maxInactiveInterval過期時(shí)間間隔sessionAttr:SPRING_SECURITY_CONTEXTSecurityContext 的序列化數(shù)據(jù)另外還有一個(gè)用于按用戶名查找 Session 的索引結(jié)構(gòu)spring:session:index:org.springframework.session.FindByIndexNameSessionRepository.PRINCIPAL_NAME這個(gè)索引結(jié)構(gòu)是實(shí)現(xiàn)并發(fā)會(huì)話控制maximumSessions的基礎(chǔ)需要查一下哪些 Session 屬于同一個(gè)用戶時(shí)就是通過這個(gè)索引去找的。4.3 序列化兩種方案JDK vs JSONSpring Session 默認(rèn)使用 JDK 序列化也就是 Java 自帶的 ObjectInputStream/ObjectOutputStream。簡(jiǎn)單但有一個(gè)致命問題序列化后的數(shù)據(jù)二進(jìn)制格式對(duì) Redis 不友好人類不可讀而且如果 Session 里放了某個(gè)內(nèi)部類對(duì)象這個(gè)類的結(jié)構(gòu)改動(dòng)后Redis 里的舊數(shù)據(jù)反序列化會(huì)直接失敗拋 ClassNotFoundException 或 InvalidClassException。另一種方案是使用 JSON 序列化通過配置自定義 RedisSerializer 實(shí)現(xiàn)。第一種方式簡(jiǎn)單可靠但是有兼容性隱患適合臨時(shí)調(diào)試。第二種方式推薦用于生產(chǎn)環(huán)境但你要為 Session 里放的對(duì)象自定義反序列化邏輯實(shí)現(xiàn)起來更繁瑣。最關(guān)鍵的一點(diǎn)是SecurityContext 里保存的 UserDetails 對(duì)象必須有默認(rèn)構(gòu)造函數(shù)并且字段不能有密碼等敏感信息直接裸露加密除外否則 JSON 反序列化時(shí)會(huì)遇到很多坑。我個(gè)人的實(shí)踐是早期直接用默認(rèn) JDK 序列化后來改了一次 UserDetails 的字段名所有在線的用戶全部登錄失效排查了半個(gè)多小時(shí)才定位到是序列化版本不匹配。后來干脆配了 JSON 序列化才徹底擺脫這類問題。Bean public RedisSerializerObject springSessionDefaultRedisSerializer() { return new GenericJackson2JsonRedisSerializer(); }注意這個(gè) Bean 的命名必須叫 springSessionDefaultRedisSerializerSpring Boot 才有自動(dòng)裝配邏輯去識(shí)別。Username 和 authorities 都會(huì)作為 JSON 字段保存調(diào)試起來很直觀。5. 完整測(cè)試代碼與驗(yàn)證步驟5.1 測(cè)試用 Controller 代碼整合做完要驗(yàn)證效果我習(xí)慣用一個(gè)帶 Session 讀寫和當(dāng)前用戶信息的接口來實(shí)測(cè)RestController RequestMapping(/demo) public class DemoController { GetMapping(/set) public String setSession(HttpServletRequest request, String value) { request.getSession().setAttribute(demoKey, value); return set value; } GetMapping(/get) public String getSession(HttpServletRequest request) { Object value request.getSession().getAttribute(demoKey); return value value; } GetMapping(/user) public String currentUser() { Object principal SecurityContextHolder.getContext() .getAuthentication() .getPrincipal(); return user principal.toString(); } GetMapping(/admin) PreAuthorize(hasRole(ADMIN)) public String admin() { return admin ok; } }這里的 PreAuthorize 需要額外開啟方法級(jí)安全校驗(yàn)在配置類或啟動(dòng)類上加 EnableGlobalMethodSecurity(prePostEnabled true)Spring Boot 2.7或 EnableMethodSecuritySpring Boot 3.x。5.2 多節(jié)點(diǎn)模擬與負(fù)載均衡實(shí)測(cè)先本地啟動(dòng)一個(gè)實(shí)例端口是 8080mvn spring-boot:run -Dspring-boot.run.arguments--server.port8080再啟動(dòng)一個(gè)實(shí)例端口改成 8081mvn spring-boot:run -Dspring-boot.run.arguments--server.port8081然后用 Nginx 把兩個(gè)端口做負(fù)載均衡或者直接用 Postman 分別請(qǐng)求兩個(gè)端口來模擬節(jié)點(diǎn)切換。第一步請(qǐng)求 8080 的 /demo/set拼上 valuehello拿到響應(yīng)里的 JSESSIONID Cookie。第二步拿著同一個(gè) Cookie請(qǐng)求 8081 的 /demo/get如果返回 value hello說明 Session 成功從 8080 共享到了 8081Redis 中間層生效。第三步請(qǐng)求 8080 的 /login用實(shí)現(xiàn)了 UserDetailsService 的賬號(hào)登錄登錄之后拿到新的 JSESSIONID也可能沿用同一個(gè)看 SessionId 策略請(qǐng)求 8081 的 /user能正常獲取當(dāng)前用戶名說明 SecurityContext 也成功跨節(jié)點(diǎn)恢復(fù)。5.3 檢查 Redis 數(shù)據(jù)的三種方式驗(yàn)證完業(yè)務(wù)接口最好去 Redis 里看一眼數(shù)據(jù)到底存了什么。命令行方式redis-cli keys * type spring:session:sessions:xxx hgetall spring:session:sessions:xxx可視化工具方面我常用 Another Redis Desktop Manager連接后可以直接看 Hash 結(jié)構(gòu)比較直觀。還有一種情況RDB 持久化開啟后可以在 dump.rdb 里看到 Session 數(shù)據(jù)。但這只作為排查輔助手段正常驗(yàn)證功能時(shí)用 keys 命令就夠了。6. 常見問題與排查技巧實(shí)錄6.1 會(huì)話不一致現(xiàn)象癥狀是偶爾出現(xiàn)未登錄刷新一下又好。排查思路是先確認(rèn)負(fù)載均衡策略是不是輪詢?nèi)缓蠓謩e在兩個(gè)節(jié)點(diǎn)上看 Redis 里 Session 是否存在。項(xiàng)目里如果自己玩讀寫分離或者主從同步延遲也會(huì)出現(xiàn)這類問題。Redis 寫入后立即讀取如果讀到的是舊數(shù)據(jù)就是復(fù)制延遲問題。一般可以通過強(qiáng)制走主庫(kù)讀來解決或者把 Session 的 Key 做一致性哈希分片但這個(gè)復(fù)雜度就高了。6.2 反序列化異常表現(xiàn)是登錄后正常第二次請(qǐng)求開始拋異常常見報(bào)錯(cuò)有Failed to deserialize object typejava.lang.ClassNotFoundExceptionInvalidClassException原因通常是 Session 里放的對(duì)象沒有默認(rèn)構(gòu)造函數(shù)、類結(jié)構(gòu)變更、JDK 序列化與 JSON 序列化混用等。排查方法是看 Redis 里存的內(nèi)容用 JSON 序列化時(shí)直接看字段JDK 序列化時(shí)就是二進(jìn)制亂碼不好排查。這類問題最有效的規(guī)避手段是統(tǒng)一序列化方案并且 Session 里放的對(duì)象 DTO 化不要直接放實(shí)體類。6.3 CSRF 問題導(dǎo)致登錄失效癥狀是最開始登錄沒問題過一段時(shí)間再次提交登錄發(fā)現(xiàn)沒有生效或者表單提交后 403。原因是項(xiàng)目里保留了 CSRF 防護(hù)Spring Security 默認(rèn)把 CSRF Token 也存到了 Session 中。由于某些原因 Token 過期或 Session 被重建Token 不匹配導(dǎo)致請(qǐng)求被拒絕。處理方法保留 CSRF 的項(xiàng)目確保頁(yè)面里的 Token 是從當(dāng)前 Session 讀出并動(dòng)態(tài)渲染的。前后端分離項(xiàng)目可以禁用 CSRF但前提是接口做 Token 鑒權(quán)比如 JWT。調(diào)試階段直接禁用 CSRF 快速驗(yàn)證但上線前記得評(píng)估。我個(gè)人的習(xí)慣是有頁(yè)面的項(xiàng)目保留 CSRF純 API 項(xiàng)目禁用。至于很多人糾結(jié)的“禁用 CSRF 后安全性下降”問題純 API 項(xiàng)目主要靠 Token 認(rèn)證而不是 Cookie風(fēng)險(xiǎn)是可控的。6.4 并發(fā)會(huì)話控制不生效配置了 maximumSessions(2)但同一用戶登錄第三個(gè)設(shè)備時(shí)舊的 Session 沒有被踢下線。原因一般是索引數(shù)據(jù)失準(zhǔn)也就是 Redis 里 FindByIndexNameSessionRepository.PRINCIPAL_NAME 這個(gè)索引沒有正確維護(hù)。常見情況是用戶信息變更后principal 名稱變化舊的索引還保留著。解決方法是查一下核心配置里 setIndexName 是否被正確設(shè)置或者干脆重寫注冊(cè)一個(gè) FindByIndexNameSessionRepository 的 Bean確保索引同步更新。6.5 Session 過期時(shí)間混亂癥狀是明明配置了 30 分鐘但實(shí)際過了幾分鐘就失效。先排查 spring.session.timeout 是否生效。注意 server.servlet.session.timeout 這個(gè)參數(shù)在 Spring Boot 2.x 里也會(huì)對(duì) Session 生效如果兩個(gè)都配置了要搞清楚哪個(gè)優(yōu)先級(jí)更高。再排查 Redis 的過期策略和內(nèi)存淘汰機(jī)制。如果 Redis 設(shè)置了 maxmemory-policy allkeys-lru那內(nèi)存壓力大時(shí)Redis 可能把 Session Key 給淘汰掉導(dǎo)致 Session 提前失效。這個(gè)要特別留個(gè)心眼生產(chǎn)環(huán)境給 Session 用的 Redis 實(shí)例要單獨(dú)規(guī)劃不要和緩存數(shù)據(jù)混用一個(gè)庫(kù)尤其不要開 LRU 淘汰策略。6.6 安全配置里踩過的坑匯總登錄接口必須在 permitAll 里否則登錄請(qǐng)求直接被攔截。defaultSuccessUrl 只在直接訪問登錄頁(yè)時(shí)生效如果用戶是訪問受保護(hù)資源被重定向到登錄頁(yè)的登錄成功后會(huì)回到原資源此時(shí) true 參數(shù)決定是否強(qiáng)制跳轉(zhuǎn)到默認(rèn)頁(yè)。靜態(tài)資源CSS、JS、圖片要 permitAll否則頁(yè)面樣式加載不出來瀏覽器調(diào)試器里一片紅容易誤判成框架問題。logout 配置里 deleteCookies 建議加上 JSESSIONID否則退出登錄后 Cookie 還存在下次訪問還會(huì)帶一個(gè)無(wú)效的 SessionId。7. 一些實(shí)操經(jīng)驗(yàn)和擴(kuò)展思路這套整合方案我用過不少實(shí)際項(xiàng)目有幾點(diǎn)經(jīng)驗(yàn)值得單列出來分享。第一序列化方案盡量在生產(chǎn)環(huán)境用 JSON別貪圖默認(rèn) JDK 序列化的省事。JDK 序列化在代碼迭代時(shí)帶來的版本兼容問題比配置 JSON 的麻煩更讓人頭疼。第二Redis 實(shí)例要獨(dú)立規(guī)劃。把 Session 和業(yè)務(wù)緩存混在一起出問題時(shí)互相干擾尤其遇到 Redis 內(nèi)存淘汰Session 被無(wú)辜清掉排查場(chǎng)景非常隱蔽。第三從安全性角度考慮Session 里不要放敏感明文數(shù)據(jù)。Session 存到 Redis 后能訪問這個(gè) Redis 的人就能看到這些數(shù)據(jù)Redis 本身沒有強(qiáng)認(rèn)證機(jī)制權(quán)限控制必須做好。再往深了走可以擴(kuò)展的方向有這么幾個(gè)Session 固定攻擊防護(hù)Spring Security 默認(rèn)會(huì)在認(rèn)證成功后輪換 SessionId但在配置里顯式確認(rèn) changeSessionId 策略是安全的。多端登錄、移動(dòng)端和 PC 端并存場(chǎng)景需要在這種安全性和便利性之間做權(quán)衡。分布式場(chǎng)景下的踢人下線功能基于 Spring Session 的事件監(jiān)聽SessionDestroyedEvent / SessionExpiredEvent可以實(shí)現(xiàn)被頂號(hào)下線的業(yè)務(wù)邏輯。Redis 高可用和連接穩(wěn)定性Spring Session 對(duì) Redis 的依賴是強(qiáng)依賴Redis 掛掉整個(gè)應(yīng)用的登錄體系全部癱瘓。所以要考慮 Redis Sentinel 或者 Cluster同時(shí)本地應(yīng)用層要做好快速失敗和告警。性能調(diào)優(yōu)Session 數(shù)據(jù)量大的情況Redis 網(wǎng)絡(luò) IO 會(huì)成為瓶頸?？梢宰?Session 數(shù)據(jù)瘦身盡量減少存入 Session 的對(duì)象大小該用的分頁(yè)放數(shù)據(jù)庫(kù)的就別塞 Session 里堆積。項(xiàng)目上線之后我通常會(huì)加一個(gè)監(jiān)控定時(shí)掃描 Redis 里 Session Key 的數(shù)量和過期分布。這能在問題發(fā)生前提前看到風(fēng)險(xiǎn)比等用戶反饋投訴要主動(dòng)得多。如果哪天生產(chǎn)環(huán)境用戶突然開始集體掉線記得第一反應(yīng)去查 Redis 的慢查詢?nèi)罩竞蛢?nèi)存狀況大概率能快速定位問題。最后補(bǔ)充一個(gè)小技巧本地調(diào)試時(shí)用兩個(gè)不同端口的實(shí)例加 Postman 手動(dòng)攜帶 Cookie是最快的驗(yàn)證手段。每次檢查 Redis 數(shù)據(jù)前先看下系統(tǒng)時(shí)間確認(rèn)時(shí)區(qū)沒有偏移否則 Session 過期時(shí)間的計(jì)算會(huì)讓你一頭霧水。這套鏈路到現(xiàn)在我已經(jīng)跑通好多回了照著配一遍半小時(shí)內(nèi)能驗(yàn)證完整個(gè)流程。