說實(shí)話寫這篇東西的起因很直接我接手過一個(gè)訪問量正在往上走的項(xiàng)目系統(tǒng)之前一直是單機(jī)部署內(nèi)網(wǎng)壓測(cè)、外網(wǎng)訪問都挺正?？梢坏┌褢?yīng)用從1個(gè)實(shí)例擴(kuò)到3個(gè)實(shí)例線上立刻出問題。用戶前一個(gè)請(qǐng)求還在正常操作下一個(gè)請(qǐng)求回來就被引導(dǎo)去重新登錄客服那邊一天能收到幾十條“為什么老讓我重新登錄”的反饋。我排查了整整兩天中間試過調(diào)負(fù)載均衡策略、改Tomcat配置效果都不徹底最后拍板換成了標(biāo)題里這套組合Redis Spring Session。這不是網(wǎng)上常說的“臨時(shí)繞過”而是把Session的存儲(chǔ)位置從根本上搬到了應(yīng)用之外讓每一個(gè)實(shí)例都變成無狀態(tài)節(jié)點(diǎn)。如果你正在做微服務(wù)拆分、多實(shí)例部署或者只是單純想把單機(jī)應(yīng)用水平擴(kuò)容這套思路應(yīng)該能給你一個(gè)比較徹底、能直接落地的解決路徑。下面我把整個(gè)問題的來龍去脈、原理、實(shí)操步驟和上線后踩過的坑都梳理一遍內(nèi)容會(huì)偏“實(shí)戰(zhàn)記錄”風(fēng)格你可以邊看邊在本地復(fù)現(xiàn)。1. 單機(jī)Session的局限性多實(shí)例部署后為什么用戶被瘋狂踢下線1.1 一個(gè)真實(shí)故障輪詢策略導(dǎo)致用戶批量掉線先說當(dāng)時(shí)的現(xiàn)象。系統(tǒng)從單機(jī)擴(kuò)到3個(gè)實(shí)例前面掛了負(fù)載均衡策略是最常用的“輪詢”。邏輯上沒什么問題3臺(tái)機(jī)器平均分擔(dān)流量哪臺(tái)都能處理請(qǐng)求。結(jié)果用戶一登錄請(qǐng)求被分到實(shí)例A登錄成功JSESSIONID寫進(jìn)瀏覽器Cookie刷新頁(yè)面后下一個(gè)請(qǐng)求被輪詢到實(shí)例B實(shí)例B在自己的本地內(nèi)存里根本找不到這個(gè)Session于是判定用戶未登錄直接重定向到登錄頁(yè)。最迷惑人的是這個(gè)問題不是100%必現(xiàn)。同一個(gè)用戶點(diǎn)幾次有時(shí)能保持登錄有時(shí)被踢出來完全取決于當(dāng)前請(qǐng)求被分發(fā)到哪臺(tái)機(jī)器。我在本地復(fù)現(xiàn)的時(shí)候開著開發(fā)者工具看Network面板清一色的302跳轉(zhuǎn)Cookie明明沒丟服務(wù)器就是不認(rèn)。后來往日志里加了節(jié)點(diǎn)信息才發(fā)現(xiàn)所有“登錄無效”的請(qǐng)求都落在非登錄節(jié)點(diǎn)上。到這一步問題的定位已經(jīng)很明確HttpSession默認(rèn)只存在于單個(gè)JVM進(jìn)程內(nèi)實(shí)例之間互相不知道對(duì)方手里的Session。1.2 理解HttpSession的“本地宿命”狀態(tài)為什么只在單個(gè)實(shí)例里Java Web開發(fā)里HttpSession的默認(rèn)實(shí)現(xiàn)類是存在應(yīng)用服務(wù)器內(nèi)存里的也就是Tomcat、Jetty這類容器的JVM堆。當(dāng)你在代碼里執(zhí)行request.getSession().setAttribute(user, user)底層就是在當(dāng)前實(shí)例的堆內(nèi)存里維護(hù)一個(gè)Map結(jié)構(gòu)key是Session IDvalue是屬性集合。這個(gè)Map的生命周期被死死綁定在單個(gè)JVM上。單機(jī)部署時(shí)沒有問題因?yàn)樗姓?qǐng)求都打到同一個(gè)JVMSession數(shù)據(jù)天然可見。但一旦拆成多個(gè)實(shí)例每個(gè)實(shí)例都有自己獨(dú)立的內(nèi)存A實(shí)例保存的Session對(duì)B實(shí)例來說就是“不存在的數(shù)據(jù)”。負(fù)載均衡把請(qǐng)求撒到不同實(shí)例上時(shí)用戶會(huì)話自然就“丟”了。本質(zhì)是會(huì)話狀態(tài)Session State和計(jì)算節(jié)點(diǎn)Application Instance被綁死在一起橫向擴(kuò)容時(shí)狀態(tài)沒有跟著擴(kuò)容。1.3 ip_hash和Session復(fù)制為什么只是“緩解”而不是“修復(fù)”我第一反應(yīng)是改負(fù)載均衡策略把輪詢改成ip_hash讓同一IP的請(qǐng)求固定打到同一臺(tái)實(shí)例。這個(gè)方案在內(nèi)部辦公網(wǎng)絡(luò)環(huán)境下驗(yàn)證是有效的但放到公網(wǎng)環(huán)境就露餡了。移動(dòng)網(wǎng)絡(luò)下用戶經(jīng)常切換基站出口IP會(huì)變化公司、家庭、4G/5G網(wǎng)絡(luò)來回切換時(shí)IP也不固定還有一些代理和NAT場(chǎng)景同一個(gè)用戶每次請(qǐng)求的源IP根本不是同一個(gè)。IP一變化ip_hash就把請(qǐng)求分到另一臺(tái)實(shí)例用戶一樣被踢。更麻煩的是即使IP一直穩(wěn)定如果某臺(tái)實(shí)例要做滾動(dòng)發(fā)布或重啟固定在這臺(tái)實(shí)例上的所有在線用戶會(huì)在重啟期間集體掉線。ip_hash本質(zhì)上是在“請(qǐng)求入口”層面想辦法把用戶留在同一個(gè)節(jié)點(diǎn)上它沒有解決“Session狀態(tài)不共享”的根因只是降低了狀態(tài)串臺(tái)的概率。我也看過Session復(fù)制方案。Tomcat支持把Session變更廣播到集群中的其他節(jié)點(diǎn)這樣每個(gè)實(shí)例都復(fù)制一份全量Session。但復(fù)制帶來的問題同樣明顯隨著在線用戶增多集群內(nèi)需要同步的數(shù)據(jù)量成倍增長(zhǎng)廣播風(fēng)暴、網(wǎng)絡(luò)開銷、延遲抖動(dòng)很快會(huì)出現(xiàn)。而且這個(gè)方案強(qiáng)依賴具體應(yīng)用服務(wù)器廠商的實(shí)現(xiàn)換容器、換云平臺(tái)時(shí)兼容成本很高。Session復(fù)制把狀態(tài)從一個(gè)節(jié)點(diǎn)復(fù)制到所有節(jié)點(diǎn)本質(zhì)上還是在“單機(jī)Session”的框架里打轉(zhuǎn)治標(biāo)不治本。2. Redis Spring Session的組合原理這為什么算“最終方案”2.1 Spring Session接管了Session的生命周期而不是存?zhèn)€key那么簡(jiǎn)單要理解為什么這套組合能解決問題先搞清楚Spring Session干了什么。Spring Session不是一個(gè)簡(jiǎn)單的“Session工具類”它的核心是通過一個(gè)Servlet過濾器——SessionRepositoryFilter——把應(yīng)用原本使用的HttpSession實(shí)現(xiàn)整個(gè)替換掉。具體流程是這樣的請(qǐng)求進(jìn)入Servlet容器后SessionRepositoryFilter會(huì)先把原始的HttpServletRequest包裝成一個(gè)SessionRepositoryRequestWrapper。當(dāng)你調(diào)用request.getSession()時(shí)它不再?gòu)娜萜鞅镜氐腟essionManager里拿對(duì)象而是從Spring Session配置好的SessionRepository里去取。這個(gè)SessionRepository可以是基于Redis、JDBC、MongoDB等任意持久化存儲(chǔ)實(shí)現(xiàn)我們這里用的是RedisSessionRepository。整套機(jī)制對(duì)外暴露的接口仍然是標(biāo)準(zhǔn)的HttpSession所以業(yè)務(wù)代碼基本不用改動(dòng)以前怎么用session.setAttribute()現(xiàn)在還是怎么用。Spring Session在背后幫你完成了Session的創(chuàng)建、讀取、寫入、過期刪除并且把數(shù)據(jù)序列化后存到Redis。這里有一個(gè)關(guān)鍵點(diǎn)Session的狀態(tài)不再存放在應(yīng)用實(shí)例的本地內(nèi)存而是被抽離到一個(gè)獨(dú)立的、所有實(shí)例都能訪問的存儲(chǔ)層。2.2 Redis里到底存了哪些key一個(gè)登錄用戶的數(shù)據(jù)結(jié)構(gòu)長(zhǎng)什么樣光說“把Session存到Redis”有點(diǎn)抽象看完Redis里的實(shí)際數(shù)據(jù)結(jié)構(gòu)你會(huì)有更直觀的理解。Spring Session在Redis中主要維護(hù)以下幾類key。第一類是主數(shù)據(jù)key默認(rèn)前綴是spring:session:sessions:sessionId類型是Hash。這個(gè)Hash里存了Session的創(chuàng)建時(shí)間、最后訪問時(shí)間、最大不活躍間隔、以及你通過setAttribute寫入的每一個(gè)業(yè)務(wù)屬性。比如你用session.setAttribute(loginUser, userInfo)Redis里就會(huì)多出一個(gè)fieldfield名是sessionAttr:loginUservalue是序列化之后的用戶信息。第二類是過期索引key格式是spring:session:expirations:timestamp類型是Set。這里面保存了一批即將在指定時(shí)間點(diǎn)過期的Session ID供后臺(tái)任務(wù)定點(diǎn)掃描使用。Spring Session并不是完全依賴Redis的key過期機(jī)制來清理Session因?yàn)镽edis key過期事件并不可靠可能丟失、可能延遲。它的策略是每個(gè)被訪問的Session都會(huì)刷新自己的最后訪問時(shí)間同時(shí)由一個(gè)專門的維護(hù)任務(wù)在到達(dá)過期時(shí)間點(diǎn)時(shí)把還在集合里的Session ID找出來做顯式刪除。第三類是查詢索引key格式是spring:session:findByIndexName:索引名:索引值比如按用戶名建立索引之后可以快速查出某個(gè)用戶當(dāng)前對(duì)應(yīng)的Session列表。做強(qiáng)制下線、在線用戶列表這類功能時(shí)這個(gè)索引很有用。通過這幾種key的組合Spring Session把Session的讀寫、過期、查詢都安排得明明白白。Redis本身就是KV存儲(chǔ)Hash結(jié)構(gòu)天然適合存儲(chǔ)“屬性集合”這種數(shù)據(jù)形態(tài)TTL機(jī)制又和Session的過期時(shí)間能對(duì)應(yīng)上。選Redis的根本原因不是因?yàn)樗芫彺娑且驗(yàn)樗峁┝艘徽追植际江h(huán)境都能訪問的、帶超時(shí)能力的、結(jié)構(gòu)足夠靈活的數(shù)據(jù)存儲(chǔ)能力。2.3 這套組合帶來的三個(gè)直接收益收益是很直觀的。第一是實(shí)例徹底無狀態(tài)化。應(yīng)用節(jié)點(diǎn)不再持有用戶狀態(tài)新增機(jī)器、縮減機(jī)器、滾動(dòng)重啟對(duì)在線用戶沒有任何影響。用戶在某臺(tái)機(jī)器上登錄下一次請(qǐng)求被負(fù)載均衡分到另一臺(tái)機(jī)器依舊能從Redis里拿到同一個(gè)Session。擴(kuò)容從“有狀態(tài)擴(kuò)容”變成了“無狀態(tài)擴(kuò)容”技術(shù)上輕松了一個(gè)量級(jí)。第二是故障影響面大幅縮小。以前如果一臺(tái)實(shí)例宕機(jī)那臺(tái)機(jī)器上的所有在線用戶集體掉線?，F(xiàn)在實(shí)例宕機(jī)只要Redis集群還穩(wěn)著用戶根本感知不到后端少了一臺(tái)機(jī)器請(qǐng)求被自動(dòng)分發(fā)到其他健康實(shí)例Session照?？捎?。第三是統(tǒng)一了會(huì)話管理能力。你可以通過Redis里的Session數(shù)據(jù)做全局的用戶登錄態(tài)清理比如后臺(tái)強(qiáng)制踢人下線、限制賬號(hào)同時(shí)在多端登錄、構(gòu)建實(shí)時(shí)在線用戶列表。這在單機(jī)Session時(shí)代幾乎不可想象但在多個(gè)微服務(wù)共享同一個(gè)Redis時(shí)這些功能實(shí)現(xiàn)起來非常順手。很多團(tuán)隊(duì)最后選這套方案不只是為了“解決掉線”而是為了把會(huì)話能力沉淀成一套基礎(chǔ)設(shè)施。3. 實(shí)操落地從依賴引入到雙實(shí)例驗(yàn)證3.1 依賴和版本選型Spring Boot 2.x/3.x別搞混直接給可用的依賴清單我用的是Maven。假設(shè)你的項(xiàng)目是標(biāo)準(zhǔn)的Spring Boot Web應(yīng)用需要引入三個(gè)starterdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.session/groupId artifactIdspring-session-data-redis/artifactId /dependency版本號(hào)我沒有手動(dòng)指定而是交給Spring Boot的依賴管理統(tǒng)一控制。這里要特別提醒spring-session-data-redis的版本必須和Spring Boot版本匹配最省心的做法就是讓Spring Boot BOM來管理它。自己?jiǎn)为?dú)指定版本很容易踩到API不兼容的坑尤其是Spring Boot 3.x和2.x之間包名、配置項(xiàng)差異很大。我這里本地驗(yàn)證用的是Spring Boot 2.7環(huán)境但下面的配置我會(huì)同時(shí)給出Spring Boot 3.x需要調(diào)整的地方。Spring Boot 3.x把Redis配置的前綴從spring.redis.*改成了spring.data.redis.*Session相關(guān)的配置不變。碰到3.x項(xiàng)目別慣性照著舊文檔抄否則配置項(xiàng)根本不會(huì)生效。3.2 關(guān)鍵配置Redis連接、Session存儲(chǔ)與命名空間配置文件是重頭戲。先說一個(gè)最容易出錯(cuò)的點(diǎn)Spring Boot 2.x和3.x的Redis連接配置前綴不一樣。Spring Boot 2.x的配置spring: redis: host: 127.0.0.1 port: 6379 password: abc123 database: 0 timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 max-wait: 3sSpring Boot 3.x的配置spring: data: redis: host: 127.0.0.1 port: 6379 password: abc123 database: 0 timeout: 3s lettuce: pool: max-active: 16 max-idle: 8 min-idle: 2 max-wait: 3s兩段配置的內(nèi)容幾乎一樣唯獨(dú)嵌套層級(jí)從spring.redis變成了spring.data.redis。我用的是Lettuce客戶端“Lettuce連接池”需要單獨(dú)啟用spring.redis.lettuce.pool.*或3.x的spring.data.redis.lettuce.pool.*才會(huì)生效。如果不配連接池高并發(fā)下Lettuce很容易出現(xiàn)連接等待超時(shí)生產(chǎn)環(huán)境一定要配。Session本身的配置如下spring: session: store-type: redis timeout: 30m redis: namespace: demo-session flush-mode: on_save save-mode: on_set_attribute這里解釋幾個(gè)參數(shù)背后的含義。store-type: redis是明確告訴Spring Boot用Redis存儲(chǔ)Session不帶這個(gè)參數(shù)時(shí)Spring Boot可能會(huì)根據(jù)classpath自動(dòng)推斷但顯式寫出來更可控。timeout: 30m是Session最大不活躍間隔單位是m代表分鐘這個(gè)值最終會(huì)寫入Redis的TTL。生產(chǎn)環(huán)境要根據(jù)業(yè)務(wù)形態(tài)設(shè)置純管理后臺(tái)可以設(shè)短一點(diǎn)電商網(wǎng)站購(gòu)物車場(chǎng)景可能需要更長(zhǎng)。redis.namespace是給當(dāng)前應(yīng)用設(shè)置Redis key前綴如果多個(gè)應(yīng)用共用同一個(gè)Redis實(shí)例一定要設(shè)置不同的namespace否則不同應(yīng)用的Session數(shù)據(jù)會(huì)互相干擾。flush-mode: on_save表示Session每次請(qǐng)求處理結(jié)束時(shí)才把數(shù)據(jù)寫回Redis這是默認(rèn)模式。還有一個(gè)模式是immediate每次調(diào)用setAttribute時(shí)立刻寫Redis實(shí)時(shí)性高但性能差一般不建議生產(chǎn)環(huán)境使用。save-mode: on_set_attribute表示只要Session屬性發(fā)生變化就標(biāo)記為需要保存這是默認(rèn)行為通常不需要改動(dòng)。如果要通過Java配置類來開啟Redis Session存儲(chǔ)可以加上一個(gè)EnableRedisHttpSession注解Configuration EnableRedisHttpSession(maxInactiveIntervalInSeconds 1800) public class SessionConfig { }這個(gè)注解里可以配置最大不活躍間隔秒數(shù)和spring.session.timeout是等價(jià)的。我個(gè)人更推薦用配置文件來管理改參數(shù)時(shí)不用重新編譯打包。3.3 自定義Cookie序列化器Cookie名字、HttpOnly與SameSiteSpring Session默認(rèn)使用名為SESSION的Cookie來傳遞Session ID但很多老項(xiàng)目前端約定的是JSESSIONID。為了兼容業(yè)務(wù)系統(tǒng)通常要自定義一個(gè)CookieSerializerBean public CookieSerializer cookieSerializer() { DefaultCookieSerializer serializer new DefaultCookieSerializer(); serializer.setCookieName(JSESSIONID); serializer.setCookiePath(/); serializer.setUseHttpOnlyCookie(true); serializer.setSameSite(Lax); return serializer; }setCookiePath(/)要特別注意。如果項(xiàng)目部署在/api這類子路徑下Cookie path設(shè)置不對(duì)瀏覽器會(huì)在跨路徑請(qǐng)求時(shí)不再攜帶Cookie導(dǎo)致Session丟失。setUseHttpOnlyCookie(true)能防止JavaScript讀取Cookie降低XSS攻擊后的信息泄露風(fēng)險(xiǎn)。setSameSite(Lax)用于控制Cookie在跨站請(qǐng)求時(shí)的發(fā)送策略對(duì)前后端分離的部署方式影響很大。如果你的系統(tǒng)還有HTTPS環(huán)境可以開啟serializer.setUseSecureCookie(true)確保Cookie只通過HTTPS傳輸。3.4 雙實(shí)例聯(lián)調(diào)腳本證明Session真的共享了配置全部搞定后驗(yàn)證邏輯很簡(jiǎn)單本地起兩個(gè)應(yīng)用實(shí)例端口分別設(shè)為8081和8082然后在8081上登錄獲取Cookie再用這個(gè)Cookie去訪問8082的接口。如果8082能返回當(dāng)前登錄用戶的信息說明Session已經(jīng)成功共享。第一步先在一個(gè)終端啟動(dòng)第一個(gè)實(shí)例mvn spring-boot:run -Dspring-boot.run.arguments--server.port8081第二個(gè)終端啟動(dòng)第二個(gè)實(shí)例mvn spring-boot:run -Dspring-boot.run.arguments--server.port8082假設(shè)項(xiàng)目里有一個(gè)登錄接口/api/login和一個(gè)獲取當(dāng)前用戶的接口/api/user/info。用curl先登錄curl -i -X POST http://localhost:8081/api/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}響應(yīng)頭里能看到Set-Cookie: JSESSIONIDxxxxx; Path/; HttpOnly。把這個(gè)Cookie值記下來再去請(qǐng)求8082的接口curl -i http://localhost:8082/api/user/info \ -H Cookie: JSESSIONIDxxxxx正常返回用戶信息就是驗(yàn)證通過。這時(shí)再去Redis里檢查一下redis-cli keys demo-session:* hgetall demo-session:sessions:xxxxx能看到Session屬性已經(jīng)落在Redis里而且8082實(shí)例讀取的底層數(shù)據(jù)源是同一個(gè)Redis。這套驗(yàn)證在本地大概10分鐘就能跑完比純看理論踏實(shí)得多。4. 生產(chǎn)環(huán)境下踩過的坑亂碼、覆蓋、網(wǎng)關(guān)和內(nèi)存4.1 序列化亂碼與JSON反序列化失敗看懂根因比替換配置更重要上線運(yùn)行不到一周我就發(fā)現(xiàn)一個(gè)隱蔽問題Redis里存的Session屬性值有一大堆看不懂的字節(jié)。直接用hgetall查看某個(gè)Session時(shí)field的值長(zhǎng)這樣\xac\xed\x00\x05t\x00\x03com...這種以\xac\xed開頭的亂碼是Java標(biāo)準(zhǔn)JDK序列化機(jī)制的產(chǎn)物。Spring Session默認(rèn)使用JDK自帶的序列化器把對(duì)象轉(zhuǎn)成二進(jìn)制字節(jié)后再塞進(jìn)Redis。它的問題有兩個(gè)一是不可讀排查問題時(shí)瞪大了眼也看不出里面存的是什么二是兼容性差如果對(duì)象類的結(jié)構(gòu)發(fā)生變化比如新增字段、刪除字段舊數(shù)據(jù)反序列化時(shí)直接拋InvalidClassException。解決辦法是替換Redis序列化器。Spring Session默認(rèn)從springSessionDefaultRedisSerializer這個(gè)Bean獲取序列化器所以我只需要覆蓋這個(gè)Bean即可Bean public RedisSerializerObject springSessionDefaultRedisSerializer() { return new GenericJackson2JsonRedisSerializer(); }注意這里必須叫springSessionDefaultRedisSerializer不是隨便定義個(gè)RedisTemplate的序列化器。很多人在這里踩坑配置了RedisTemplateString,Object的序列化方式結(jié)果Session數(shù)據(jù)還是JDK序列化因?yàn)镾pring Session內(nèi)部根本不走RedisTemplate的默認(rèn)序列化邏輯。換JSON序列化之后還有一個(gè)更深的坑要提醒JSON串里默認(rèn)會(huì)帶上類信息class字段用來反序列化時(shí)確定目標(biāo)類型。一旦你的用戶類從User改名為Account或者在包里移動(dòng)了位置Redis里舊數(shù)據(jù)的類路徑已經(jīng)不存在了反序列化直接失敗。我后來定的規(guī)矩是涉及Session里保存對(duì)象的字段變更時(shí)要么提前清空線上Redis的Session前綴要么在代碼里寫一個(gè)兼容的轉(zhuǎn)換處理器。老數(shù)據(jù)有時(shí)候舍不得清但Session本來就是“丟了就讓用戶重新登錄”的臨時(shí)數(shù)據(jù)優(yōu)先保證系統(tǒng)可用比死守?cái)?shù)據(jù)更實(shí)際。4.2 用戶的并發(fā)請(qǐng)求導(dǎo)致Session覆蓋一個(gè)被低估的丟失更新問題這個(gè)坑不是馬上暴露的而是上線后功能越加越多才慢慢顯現(xiàn)?，F(xiàn)象是用戶同時(shí)打開多個(gè)瀏覽器標(biāo)簽頁(yè)在一個(gè)標(biāo)簽頁(yè)里更新了Session中的用戶資料隨后在另一個(gè)標(biāo)簽頁(yè)里操作時(shí)第一次更新“消失”了。根因要從Redis的讀寫模式說起。Spring Session在請(qǐng)求結(jié)束后把整個(gè)Session對(duì)象寫回Redis這個(gè)操作不是原子更新局部字段而是讀出Session、反序列化、修改屬性、整體寫回的過程。當(dāng)兩個(gè)請(qǐng)求分別落在兩個(gè)不同的實(shí)例上兩邊幾乎同時(shí)從Redis讀出同一個(gè)Session的同一個(gè)字段各自在本地做修改然后先后寫回Redis。后寫的那個(gè)會(huì)把先寫的覆蓋掉其中一個(gè)請(qǐng)求的修改就丟了。這種問題場(chǎng)景和并發(fā)寫數(shù)據(jù)庫(kù)記錄時(shí)的“丟失更新”完全一致只是很多人沒意識(shí)到Session也會(huì)遇到。我當(dāng)時(shí)的排查思路是確認(rèn)哪些數(shù)據(jù)會(huì)被高頻并發(fā)寫。比如用戶每次訪問時(shí)更新“最近訪問時(shí)間”這個(gè)字段就在并發(fā)時(shí)頻繁觸發(fā)覆蓋。解決辦法分兩路走一是把并發(fā)寫頻率最高的數(shù)據(jù)從Session里挪出去比如“最近訪問時(shí)間”這種數(shù)據(jù)完全可以通過Redis單獨(dú)記錄一個(gè)user:online:userId的key來管理不必塞進(jìn)Session二是盡量減少Session里的可變屬性總量Session只保留登錄憑證、用戶主鍵這類低頻變化的標(biāo)識(shí)性數(shù)據(jù)其余高頻業(yè)務(wù)數(shù)據(jù)走專門設(shè)計(jì)的Redis key。如果確實(shí)需要保留并發(fā)寫場(chǎng)景可以考慮把Session的存儲(chǔ)粒度做細(xì)或者引入分布式鎖來控制同一Session的寫并發(fā)。但我的真實(shí)感受是最佳策略不是“控制并發(fā)”而是“減少寫入”——Session的屬性越少、越穩(wěn)定這套方案就越穩(wěn)。它本質(zhì)上是一個(gè)定位標(biāo)識(shí)不是內(nèi)容倉(cāng)庫(kù)。4.3 網(wǎng)關(guān)轉(zhuǎn)發(fā)與前后端分離下的Cookie透?jìng)黜?xiàng)目改造到一定階段前端從服務(wù)端渲染換成了前后端分離請(qǐng)求統(tǒng)一走API網(wǎng)關(guān)。網(wǎng)關(guān)部署完之后又冒出一個(gè)新問題用戶明明登錄成功了緊接著請(qǐng)求業(yè)務(wù)接口卻返回401。瀏覽器里Cookie明明還在后端Session也存在Redis里但請(qǐng)求就是帶不到后端。排查下來發(fā)現(xiàn)是網(wǎng)關(guān)這一層把Cookie信息丟掉了。網(wǎng)關(guān)在轉(zhuǎn)發(fā)HTTP請(qǐng)求時(shí)如果配置里沒有顯式轉(zhuǎn)發(fā)Cookie頭后端拿到的請(qǐng)求里就不會(huì)包含JSESSIONID。后端的SessionRepository完全不知道該查找哪個(gè)Session自然判定未登錄。解決方式是在網(wǎng)關(guān)的轉(zhuǎn)發(fā)配置里把Cookie頭原樣透?jìng)?。以常見的網(wǎng)關(guān)配置為例在路由規(guī)則里加一行轉(zhuǎn)發(fā)Headerfilters: - PreserveHostHeader - RewritePath/api/(?segment.*), /$\{segment} default-filters: - DedupeResponseHeaderAccess-Control-Allow-Credentials Access-Control-Allow-Origin核心是確保轉(zhuǎn)發(fā)請(qǐng)求時(shí)保留瀏覽器提交的Cookie頭同時(shí)響應(yīng)時(shí)不要重復(fù)添加互相沖突的CORS頭?？缬蚺渲靡彩莻€(gè)關(guān)鍵點(diǎn)。前后端域名不一致時(shí)后端必須配置CORS允許攜帶憑證Bean public CorsWebFilter corsWebFilter() { CorsConfiguration config new CorsConfiguration(); config.setAllowCredentials(true); config.addAllowedOrigin(https://frontend.example.com); config.addAllowedHeader(*); config.addAllowedMethod(*); return new CorsWebFilter(source - config); }這里有一個(gè)安全限制必須要知道allowCredentials(true)時(shí)allowedOrigins不能寫成*必須指定具體域名。瀏覽器規(guī)范明確禁止攜帶憑證的跨域請(qǐng)求使用通配符來源。前端調(diào)用時(shí)也要設(shè)置withCredentials: true否則即使后端允許瀏覽器也不會(huì)主動(dòng)攜帶Cookie。這個(gè)跨域問題排查起來比較費(fèi)時(shí)我每次都會(huì)先看瀏覽器Network面板里請(qǐng)求是否帶上了Cookie再看響應(yīng)頭里Access-Control-Allow-Credentials是否為true兩步能定位90%的問題。4.4 Redis內(nèi)存持續(xù)增長(zhǎng)與session過期回收失效還有一個(gè)經(jīng)典問題系統(tǒng)跑了一段時(shí)間后Redis內(nèi)存占用越來越高明明設(shè)置了Session過期時(shí)間數(shù)據(jù)卻沒有按預(yù)期釋放。這通常不是Spring Session沒做清理而是清理機(jī)制依賴某些前提條件。Spring Session的過期清理依賴兩個(gè)關(guān)鍵機(jī)制一個(gè)是通過spring:session:expirations:timestamp集合定時(shí)掃描另一個(gè)是Redis的過期key事件通知。如果Redis實(shí)例關(guān)閉了notify-keyspace-events配置Spring Session就無法收到key過期事件來觸發(fā)后續(xù)的刪除操作。雖然掃描任務(wù)也能兜底但事件通知關(guān)閉時(shí)清理效率和實(shí)時(shí)性都會(huì)下降內(nèi)存里會(huì)殘留更多等待淘汰的Session數(shù)據(jù)。建議在Redis配置里打開必要的事件通知notify-keyspace-events Exgx這個(gè)配置項(xiàng)開啟了過期key事件和通用命令事件。生產(chǎn)環(huán)境調(diào)整Redis配置后要記得驗(yàn)證生效用config get notify-keyspace-events確認(rèn)。更需要注意的另一個(gè)坑是Redis內(nèi)存淘汰策略。如果Redis配置的maxmemory-policy是allkeys-lru那么當(dāng)內(nèi)存達(dá)到上限時(shí)Redis會(huì)從所有key里挑選最久未用的key來淘汰Session數(shù)據(jù)也會(huì)被當(dāng)成普通緩存清掉哪怕它還沒到過期時(shí)間。結(jié)果就是用戶明明還在活躍Session卻被Redis強(qiáng)制刪除用戶被莫名其妙踢下線。這種情況特別難排查因?yàn)槿罩纠锟床坏饺魏螆?bào)錯(cuò)就是偶發(fā)掉線。后來我把Redis的內(nèi)存淘汰策略改成了volatile-lru這個(gè)策略只淘汰設(shè)置了TTL的key。Session主key自帶TTL業(yè)務(wù)緩存如果不需要被淘汰可以不帶TTL。這樣既能保證Redis內(nèi)存可控又不會(huì)誤傷活躍Session。同時(shí)我還寫了一個(gè)定時(shí)巡檢腳本每天檢查一次Redis內(nèi)存增長(zhǎng)曲線和spring:session:*的key數(shù)量如果發(fā)現(xiàn)Session數(shù)量異常增多基本都是某個(gè)接口在瘋狂創(chuàng)建新Session這時(shí)會(huì)去檢查業(yè)務(wù)代碼里是不是有“一登錄就訪問request.getSession(false)并觸發(fā)創(chuàng)建新Session”的邏輯。結(jié)尾改動(dòng)之外我留下的一點(diǎn)心得整套方案落地后再回看技術(shù)層面的難度其實(shí)不算高真正的難點(diǎn)在于兩處一是意識(shí)到“Session狀態(tài)必須和實(shí)例解耦”這個(gè)根本前提二是上線后通過實(shí)際問題把方案打磨到符合業(yè)務(wù)特性。如果你還在單機(jī)架構(gòu)里提前把Session遷到Redis并不是過度設(shè)計(jì)而是一筆很劃算的“架構(gòu)保險(xiǎn)”因?yàn)榈鹊綌U(kuò)容當(dāng)天再處理緊迫感和故障壓力會(huì)讓你沒有充足時(shí)間考慮細(xì)節(jié)。我個(gè)人的體會(huì)是遷到Redis Spring Session之后最需要改變的其實(shí)是“往Session里亂塞東西”的習(xí)慣。單機(jī)時(shí)代往Session塞什么都能跑但分布式環(huán)境下Session變成了分布式共享存儲(chǔ)每一次寫入都對(duì)應(yīng)一次網(wǎng)絡(luò)請(qǐng)求加一次序列化濫用會(huì)直接把Redis拖成瓶頸。我現(xiàn)在定的原則很簡(jiǎn)單Session里只放穩(wěn)定且低頻使用的核心標(biāo)識(shí)數(shù)據(jù)比如用戶ID、登錄令牌、少量偏好設(shè)置所有需要業(yè)務(wù)計(jì)算和頻繁變化的數(shù)據(jù)單獨(dú)設(shè)計(jì)Redis緩存key或落庫(kù)。這套原則比任何技術(shù)選型都更影響長(zhǎng)期穩(wěn)定。最后分享一個(gè)實(shí)用小技巧本地開發(fā)環(huán)境可以保留內(nèi)存存儲(chǔ)只把生產(chǎn)環(huán)境切到Redis避免每個(gè)開發(fā)同學(xué)都依賴一個(gè)共享的Redis實(shí)例。具體做法是在application.yml里用多環(huán)境配置區(qū)分dev和proddev環(huán)境不配spring.session.store-type讓它走Spring Boot默認(rèn)的內(nèi)存Sessionprod環(huán)境顯式配置成redis。這樣開發(fā)調(diào)試不受Redis狀態(tài)影響線上又能享受無狀態(tài)擴(kuò)容的紅利。兩套環(huán)境隔離好開發(fā)效率和系統(tǒng)穩(wěn)定性都可以兼得。