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