1. 從一次線上故障說起為什么我的用戶“掉線”了大概半年前我們線上一個核心的Web應(yīng)用集群出了一次不大不小的故障?，F(xiàn)象很詭異部分用戶反饋在連續(xù)操作幾個頁面后系統(tǒng)會突然提示“會話已過期請重新登錄”。但與此同時其他用戶卻一切正常。運維同學(xué)檢查了負(fù)載均衡器當(dāng)時用的是Nginx的默認(rèn)輪詢策略和后端Tomcat服務(wù)器所有節(jié)點CPU、內(nèi)存、網(wǎng)絡(luò)都健康日志里也沒有明顯的錯誤。問題排查一度陷入僵局。后來我們仔細分析了用戶行為路徑發(fā)現(xiàn)了一個關(guān)鍵點出問題的用戶其請求在連續(xù)幾次操作中被負(fù)載均衡器分發(fā)到了不同的后端服務(wù)器上。而我們的用戶會話Session數(shù)據(jù)默認(rèn)是存儲在每臺Tomcat服務(wù)器的本地內(nèi)存中的。這意味著用戶A的第一次請求被分到服務(wù)器1服務(wù)器1為他創(chuàng)建了Session他的第二次請求如果被分到服務(wù)器2服務(wù)器2上根本沒有他的Session數(shù)據(jù)自然就判定為“未登錄”。這個問題的本質(zhì)就是Session丟失其根源在于無狀態(tài)的HTTP協(xié)議與有狀態(tài)的會話需求之間的矛盾而負(fù)載均衡的介入打破了會話與單一服務(wù)器的綁定關(guān)系。為了解決這個問題業(yè)界有幾種常見方案Session復(fù)制集群內(nèi)同步開銷大、Session持久化到集中存儲如Redis架構(gòu)改動大引入新組件或者我們今天要深入探討的——Session親和Session Affinity也叫“粘性會話”Sticky Session。最近在研究和測試國產(chǎn)的TongHttpServer時我發(fā)現(xiàn)它對Session親和的支持做得相當(dāng)細致和高效這讓我想起了那次踩坑經(jīng)歷。今天我就結(jié)合TongHttpServer的源碼和配置實踐把Session親和的原理、實現(xiàn)方式以及其中的門道掰開揉碎講清楚。無論你是正在評估國產(chǎn)Web服務(wù)器還是單純想深入理解負(fù)載均衡下的會話保持機制這篇文章都會給你帶來收獲。2. Session親和不是什么高深魔法而是負(fù)載均衡的“記憶術(shù)”在深入TongHttpServer之前我們必須先建立對Session親和的基本認(rèn)知。它不是一個獨立的功能而是負(fù)載均衡器Load Balancer上的一種策略。2.1 核心概念與要解決的痛點Session會話在Web開發(fā)中指服務(wù)器為了識別連續(xù)來自同一客戶端通常是瀏覽器的一系列請求而創(chuàng)建的一個有狀態(tài)的信息存儲空間。服務(wù)器會為每個新會話生成一個唯一的IDSession ID并通過Set-Cookie頭將其傳遞給瀏覽器。瀏覽器在后續(xù)請求中會通過Cookie頭攜帶這個Session ID從而讓服務(wù)器知道“你是誰”。負(fù)載均衡Load Balancing為了應(yīng)對高并發(fā)我們會部署多臺應(yīng)用服務(wù)器組成一個集群。負(fù)載均衡器作為流量入口將客戶端請求按照既定策略如輪詢、隨機、最小連接數(shù)等分發(fā)到集群中的某臺服務(wù)器上。痛點當(dāng)負(fù)載均衡策略是“無記憶”的如輪詢同一個用戶會話的多次請求很可能被分發(fā)到不同的后端服務(wù)器。如果Session數(shù)據(jù)存儲在后端服務(wù)器的本地內(nèi)存中那么除了第一次處理該Session的服務(wù)器其他服務(wù)器都無法識別這個用戶導(dǎo)致狀態(tài)丟失。Session親和Session Affinity就是為了解決這個痛點而生的。它的核心思想是負(fù)載均衡器設(shè)法將來自同一會話的所有請求都固定地分發(fā)到同一臺后端服務(wù)器上。這樣會話狀態(tài)就能在單臺服務(wù)器本地得以保持無需復(fù)雜的集群間數(shù)據(jù)同步。2.2 常見的實現(xiàn)原理實現(xiàn)Session親和關(guān)鍵在于負(fù)載均衡器如何識別“同一會話”。主流方法有以下幾種基于Cookie插入Cookie Insertion原理負(fù)載均衡器在第一個來自客戶端的響應(yīng)中主動向客戶端瀏覽器注入一個自己生成的Cookie例如BALANCEIDServerA。此后客戶端每次請求都會攜帶這個Cookie。負(fù)載均衡器通過解析這個Cookie的值就知道該將請求指向哪臺后端服務(wù)器。優(yōu)點對后端服務(wù)器完全透明服務(wù)器無需任何改造。缺點負(fù)載均衡器需要解析和修改HTTP報文性能有輕微損耗如果客戶端禁用了Cookie此方法失效?；贑ookie被動學(xué)習(xí)Cookie Passive原理負(fù)載均衡器不主動設(shè)置Cookie而是“偷看”后端應(yīng)用服務(wù)器設(shè)置的Session Cookie如JSESSIONID。它記住JSESSIONID與后端服務(wù)器的映射關(guān)系。當(dāng)帶有相同JSESSIONID的新請求到來時就將其轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)器。優(yōu)點同樣對后端透明且遵循了應(yīng)用原有的Cookie機制。缺點需要負(fù)載均衡器能夠識別出應(yīng)用使用的Session Cookie名可配置在Session創(chuàng)建后的第一個請求周期內(nèi)可能仍存在親和性未建立的風(fēng)險。基于源IP地址Source IP Affinity原理負(fù)載均衡器簡單地根據(jù)客戶端的源IP地址進行哈希計算將同一IP的所有請求都轉(zhuǎn)發(fā)到固定的后端服務(wù)器。優(yōu)點實現(xiàn)簡單效率高不依賴Cookie。缺點在NAT網(wǎng)絡(luò)地址轉(zhuǎn)換環(huán)境下如公司網(wǎng)關(guān)、大型網(wǎng)吧大量不同用戶可能共享同一個公網(wǎng)IP導(dǎo)致負(fù)載嚴(yán)重不均。同時客戶端IP動態(tài)變化如移動網(wǎng)絡(luò)切換也會導(dǎo)致親和失效。了解了這些通用原理我們再來看看TongHttpServer是如何設(shè)計和實現(xiàn)它的Session親和功能的。3. TongHttpServer的Session親和實現(xiàn)深度解析TongHttpServer作為一款高性能、國產(chǎn)化的Web服務(wù)器和反向代理其Session親和功能設(shè)計兼顧了靈活性和效率。根據(jù)其官方文檔和實際配置分析它主要實現(xiàn)了上述的基于Cookie被動學(xué)習(xí)和基于源IP地址兩種模式并且提供了一些精細化的控制參數(shù)。3.1 核心配置與工作流程在TongHttpServer的配置文件中通常是server.xml或獨立的負(fù)載均衡配置Session親和相關(guān)的配置通常位于反向代理upstream或負(fù)載均衡模塊部分。一個典型的配置示例如下upstream namebackend_cluster server address192.168.1.101:8080 weight10/ server address192.168.1.102:8080 weight10/ server address192.168.1.103:8080 weight10/ !-- 負(fù)載均衡策略配置 -- load_balance modesession_affinity !-- 指定用于識別會話的Cookie名稱通常對應(yīng)后端應(yīng)用的Session Cookie名 -- session_cookie nameJSESSIONID / !-- 親和性過期時間秒超過此時間未收到該會話的請求映射關(guān)系將被清除 -- affinity_timeout1800/affinity_timeout !-- 可選啟用基于源IP的備用親和策略 -- source_ip_fallbackon/source_ip_fallback /load_balance /upstream工作流程詳解初次請求與映射建立用戶首次訪問請求到達TongHttpServer。TongHttpServer根據(jù)配置的負(fù)載均衡策略如加權(quán)輪詢選擇一個后端服務(wù)器假設(shè)是192.168.1.101轉(zhuǎn)發(fā)請求。后端應(yīng)用處理請求創(chuàng)建新會話并在響應(yīng)頭中通過Set-Cookie: JSESSIONIDabc123設(shè)置Session ID。TongHttpServer在將響應(yīng)返回給客戶端之前會“窺探”響應(yīng)頭。它發(fā)現(xiàn)Set-Cookie頭中包含了配置的session_cookie即JSESSIONID。TongHttpServer在內(nèi)部建立一個映射表JSESSIONIDabc123-后端服務(wù)器192.168.1.101。這個映射會記錄時間戳并受affinity_timeout管理。后續(xù)請求與親和路由用戶發(fā)起第二次請求瀏覽器會自動在Cookie頭中攜帶Cookie: JSESSIONIDabc123。請求再次到達TongHttpServer。它首先解析請求中的Cookie查找JSESSIONID的值。根據(jù)abc123這個值去內(nèi)部的映射表中查找。成功找到映射關(guān)系指向192.168.1.101。TongHttpServer忽略配置的輪詢等策略直接將請求轉(zhuǎn)發(fā)給192.168.1.101。后端服務(wù)器101識別出abc123是其內(nèi)存中的有效Session順利處理請求用戶感覺不到任何中斷。映射的維護與清理超時清理affinity_timeout參數(shù)至關(guān)重要。如果某個Session ID在設(shè)定的時間如1800秒內(nèi)沒有再次出現(xiàn)TongHttpServer會從映射表中刪除這條記錄。這防止了映射表無限膨脹也處理了用戶關(guān)閉瀏覽器導(dǎo)致會話自然結(jié)束的情況。服務(wù)器故障如果映射表指向的后端服務(wù)器被標(biāo)記為下線或健康檢查失敗TongHttpServer會清除所有映射到該服務(wù)器的親和記錄。對于新的請求它會重新進行負(fù)載均衡選擇并建立新的映射。對于已失效映射的請求它也會重新選擇服務(wù)器并更新映射。3.2 關(guān)鍵設(shè)計剖析性能與可靠性TongHttpServer在實現(xiàn)這套機制時有幾個設(shè)計點值得稱道高效的映射表數(shù)據(jù)結(jié)構(gòu)為了應(yīng)對高并發(fā)下的快速查找映射表通常采用高性能的哈希表Hash Table或類似結(jié)構(gòu)來實現(xiàn)。鍵Key是Session ID字符串值Value是后端服務(wù)器的標(biāo)識符和最后訪問時間戳。這保證了O(1)時間復(fù)雜度的查找和更新效率。被動學(xué)習(xí)的優(yōu)勢采用“被動學(xué)習(xí)”模式意味著TongHttpServer完全尊重后端應(yīng)用的行為。應(yīng)用可以使用任何它喜歡的Session管理方案如基于內(nèi)存、基于Redis只要它通過標(biāo)準(zhǔn)的Set-Cookie頭來傳遞Session ID即可。這種解耦使得TongHttpServer的親和功能具有很好的通用性。source_ip_fallback備用策略這是一個很實用的功能。當(dāng)啟用時如果請求中沒有找到有效的Session Cookie例如用戶首次請求或客戶端禁用CookieTongHttpServer會回退到基于源IP的哈希策略。這為不支持Cookie的場景提供了一個基本的親和保障雖然存在之前提到的NAT環(huán)境負(fù)載不均的問題但總比完全沒有親和性要好。與健康檢查的聯(lián)動TongHttpServer的Session親和不是孤立工作的。它會與后端服務(wù)器的健康檢查狀態(tài)緊密聯(lián)動。一旦某臺服務(wù)器健康檢查失敗不僅新的請求不會發(fā)往該服務(wù)器所有之前綁定到它的Session親和映射也會被立即失效。這確保了故障轉(zhuǎn)移的自動進行盡管會導(dǎo)致綁定到故障服務(wù)器上的用戶會話中斷需要重新登錄但這是保證服務(wù)整體可用性的必要代價。注意Session親和解決的是會話狀態(tài)問題但它本身并不提供會話數(shù)據(jù)的高可用。如果綁定到的后端服務(wù)器宕機即使TongHttpServer將后續(xù)請求轉(zhuǎn)發(fā)到其他健康的服務(wù)器該用戶的會話數(shù)據(jù)也會丟失。因此對于要求高可用的場景仍需結(jié)合集中式會話存儲如Redis來使用。4. 實戰(zhàn)配置與避坑指南理解了原理我們來看看如何在TongHttpServer中實際配置和使用Session親和以及會遇到哪些“坑”。4.1 配置步驟詳解假設(shè)我們有一個由三臺Tomcat應(yīng)用服務(wù)器組成的集群TongHttpServer作為反向代理和負(fù)載均衡器。確認(rèn)后端Session Cookie名稱首先你需要知道你的應(yīng)用用什么名字來設(shè)置Session Cookie。對于Java Servlet應(yīng)用默認(rèn)是JSESSIONID對于PHP可能是PHPSESSID其他框架也各有不同。查看瀏覽器開發(fā)者工具中“網(wǎng)絡(luò)”選項卡的請求/響應(yīng)頭即可確認(rèn)。編輯TongHttpServer配置文件找到負(fù)載均衡上游upstream配置部分。配置Session親和參數(shù)upstream nameapp_servers server address10.0.1.11:8080 weight5/ server address10.0.1.12:8080 weight5/ server address10.0.1.13:8080 weight5/ load_balance modesession_affinity !-- 將name屬性值替換為你的應(yīng)用實際使用的Cookie名 -- session_cookie nameJSESSIONID / !-- 超時時間建議略大于應(yīng)用服務(wù)器的Session超時時間 -- affinity_timeout3600/affinity_timeout !-- 對于內(nèi)部系統(tǒng)或可確保Cookie可用的場景可以關(guān)閉IP回退 -- source_ip_fallbackoff/source_ip_fallback /load_balance /upstream配置對應(yīng)的訪問路由virtual_host namewww.yourdomain.com location path/ proxy_pass http://app_servers; # 其他代理參數(shù)如設(shè)置正確的Host頭等 proxy_set_header Host $host; /location /virtual_host重載配置保存配置文件并使用TongHttpServer的管理命令重載配置使其生效。4.2 常見問題與排查技巧實錄即使配置正確在實際運行中也可能遇到問題。下面是我總結(jié)的一些常見場景和排查思路。問題1用戶會話仍然隨機丟失?？赡茉駻Cookie名稱配置錯誤。排查使用瀏覽器開發(fā)者工具或curl -I命令仔細檢查應(yīng)用服務(wù)器返回的Set-Cookie頭中的具體名稱確保與TongHttpServer配置中的session_cookie name...完全一致包括大小寫。解決修正配置文件中的Cookie名稱。可能原因B應(yīng)用生成的Session ID格式特殊或包含非法字符。排查檢查Session ID的值。TongHttpServer內(nèi)部映射表的鍵通常是字符串但如果ID中包含換行符等特殊字符可能會在解析時被意外截斷。解決確保應(yīng)用生成的Session ID是URL安全的字符串。必要時可以查閱TongHttpServer日志如果開啟了調(diào)試日志看是否有Cookie解析相關(guān)的警告?？赡茉駽affinity_timeout設(shè)置過短。排查對比TongHttpServer的affinity_timeout和應(yīng)用服務(wù)器如Tomcat的session-timeout的會話超時時間。如果TongHttpServer的超時時間更短它可能會先清理映射而應(yīng)用服務(wù)器上的Session還未過期。解決將affinity_timeout設(shè)置為略大于應(yīng)用服務(wù)器的Session超時時間。例如Tomcat默認(rèn)30分鐘1800秒可將affinity_timeout設(shè)為1900或3600秒。問題2負(fù)載嚴(yán)重不均衡某些服務(wù)器壓力巨大?？赡茉蛑饕褂昧藄ource_ip_fallback模式且用戶集中在少數(shù)NAT網(wǎng)關(guān)之后。排查檢查TongHttpServer的訪問日志或監(jiān)控看請求是否大量來自少數(shù)幾個IP。同時確認(rèn)導(dǎo)致負(fù)載不均的請求是否都是沒有Session Cookie的請求如靜態(tài)資源、首次登錄頁面。解決對于靜態(tài)資源如圖片、CSS、JS建議通過location規(guī)則將其剝離直接由TongHttpServer本地處理或指向其他上游不參與Session親和。考慮關(guān)閉source_ip_fallback強制要求會話必須基于Cookie。對于禁用Cookie的客戶端可以引導(dǎo)其啟用或接受功能限制。如果必須使用IP親和可以考慮在負(fù)載均衡器前部署一個能夠識別真實客戶端IP如通過X-Forwarded-For頭的七層代理但復(fù)雜度較高。問題3后端服務(wù)器下線后部分用戶恢復(fù)緩慢?，F(xiàn)象當(dāng)一臺后端服務(wù)器因維護或故障被移除后綁定到該服務(wù)器的用戶需要等待affinity_timeout超時后才能被重新負(fù)載均衡到其他服務(wù)器期間訪問會失敗。解決這是Session親和策略的固有缺點。TongHttpServer通常會在健康檢查失敗后立即清除相關(guān)映射。請確保你的健康檢查配置是正確且靈敏的。檢查server標(biāo)簽或健康檢查模塊的配置確保當(dāng)服務(wù)器不可用時它能被快速標(biāo)記為down狀態(tài)從而觸發(fā)親和映射的清理。問題4HTTPS環(huán)境下Cookie設(shè)置失敗?，F(xiàn)象在HTTP下工作正常切換到HTTPS后Session親和失效?？赡茉虬踩獵ookie標(biāo)志Secure。當(dāng)應(yīng)用通過HTTPS運行時它可能會設(shè)置Set-Cookie: JSESSIONIDxxx; Secure。這意味著瀏覽器只會在HTTPS請求中發(fā)送這個Cookie。如果你的TongHttpServer配置是接收HTTP請求然后以HTTP協(xié)議反向代理到后端那么瀏覽器在后續(xù)的HTTP請求中就不會發(fā)送這個Cookie導(dǎo)致TongHttpServer無法識別會話。排查檢查HTTPS響應(yīng)中的Set-Cookie頭是否包含Secure屬性。解決確保整個鏈路的一致性。最佳實踐是讓TongHttpServer也以HTTPS方式終止SSL然后以HTTP或HTTPS與后端通信。確保TongHttpServer和后端應(yīng)用關(guān)于協(xié)議和Cookie安全的配置是匹配的。實操心得在配置Session親和后一定要進行完整的測試。不僅僅是登錄后跳轉(zhuǎn)還要測試標(biāo)簽頁多開、瀏覽器刷新、會話超時重新登錄、服務(wù)器故障切換等邊界場景。監(jiān)控映射表的大小和增長情況也是一個好習(xí)慣可以提前發(fā)現(xiàn)異常。5. 進階思考Session親和與分布式會話的權(quán)衡Session親和是一個優(yōu)雅的折中方案但它并非銀彈。在架構(gòu)選型時我們需要根據(jù)具體場景在它和分布式會話之間做出權(quán)衡。選擇Session親和Sticky Session的場景應(yīng)用本身無狀態(tài)或會話內(nèi)狀態(tài)簡單會話中只存儲了少量、非關(guān)鍵的用戶標(biāo)識信息丟失后重建成本低。服務(wù)器本地緩存依賴性強應(yīng)用嚴(yán)重依賴服務(wù)器本地內(nèi)存緩存如某些計算中間結(jié)果遷移到其他服務(wù)器成本高。追求極致性能集中式會話存儲如訪問Redis會帶來額外的網(wǎng)絡(luò)延遲。對于延遲極其敏感的應(yīng)用本地內(nèi)存訪問的優(yōu)勢明顯。架構(gòu)簡單快速上線引入Redis等組件會增加系統(tǒng)復(fù)雜度和運維成本。Session親和允許你快速擴展應(yīng)用集群而無需改造應(yīng)用代碼和架構(gòu)。選擇分布式會話集中存儲如Redis的場景要求高可用性不能接受單臺后端服務(wù)器宕機導(dǎo)致用戶會話丟失。需要精確的負(fù)載均衡希望負(fù)載均衡器能完全自由地分配每一個請求實現(xiàn)最均勻的負(fù)載。會話數(shù)據(jù)量大或結(jié)構(gòu)復(fù)雜會話中存儲了大量數(shù)據(jù)復(fù)制或遷移開銷大集中管理更高效。服務(wù)器需要頻繁擴縮容或自動伸縮在云原生環(huán)境下服務(wù)器實例動態(tài)創(chuàng)建和銷毀是常態(tài)。集中式會話存儲使得后端實例真正成為無狀態(tài)、可隨意替換的單元?；旌夏Ｊ揭环N更高級的模式是結(jié)合兩者。例如使用Session親和將用戶請求固定到某臺服務(wù)器但將會話數(shù)據(jù)存儲在外部的Redis中。這樣既獲得了親和性帶來的本地性能優(yōu)勢如利用本地緩存又保證了會話數(shù)據(jù)的高可用。不過這需要應(yīng)用層代碼的支持以讀寫外部存儲的會話數(shù)據(jù)。TongHttpServer提供的Session親和功能正是為那些適合采用粘性會話策略的場景提供了一個穩(wěn)定、高效的內(nèi)置解決方案。它通過精細的配置項讓我們能夠在簡單性、性能和可靠性之間找到合適的平衡點。6. 性能調(diào)優(yōu)與監(jiān)控建議最后如果你決定在生產(chǎn)環(huán)境使用TongHttpServer的Session親和以下幾點調(diào)優(yōu)和監(jiān)控建議可供參考合理設(shè)置affinity_timeout這是最重要的參數(shù)之一。設(shè)置過長會導(dǎo)致映射表膨脹占用更多內(nèi)存且在服務(wù)器下線后用戶等待恢復(fù)時間過長。設(shè)置過短會導(dǎo)致活躍用戶的親和性意外中斷。建議設(shè)置為比應(yīng)用會話超時時間多10%-20%。監(jiān)控映射表大小如果可能通過TongHttpServer的管理接口或日志監(jiān)控內(nèi)部Session親和映射表的條目數(shù)量。它的增長應(yīng)與活躍會話數(shù)成正比。如果發(fā)現(xiàn)異常增長如遠超活躍用戶數(shù)可能是Cookie配置錯誤或發(fā)生了內(nèi)存泄漏。關(guān)注后端服務(wù)器的會話數(shù)即使使用了Session親和也建議監(jiān)控每臺后端服務(wù)器上的活躍會話數(shù)量。理論上在親和性完美工作且負(fù)載均衡初始分配均勻的情況下各服務(wù)器的會話數(shù)應(yīng)該是均衡的。如果出現(xiàn)嚴(yán)重傾斜需要檢查是否是source_ip_fallback導(dǎo)致或是某些服務(wù)器的親和映射被異常清理。壓力測試在進行壓力測試時需要模擬真實的用戶行為即同一個虛擬用戶會發(fā)送一系列有狀態(tài)的請求。觀察在高壓下Session親和的保持成功率、請求響應(yīng)時間的變化以及TongHttpServer自身的CPU和內(nèi)存消耗。配置會話驅(qū)逐策略雖然TongHttpServer管理親和映射但后端應(yīng)用服務(wù)器如Tomcat自身也有會話管理機制。確保兩者的超時和清理策略協(xié)調(diào)避免出現(xiàn)應(yīng)用服務(wù)器會話已過期但TongHttpServer仍將請求轉(zhuǎn)發(fā)過去的情況雖然應(yīng)用會處理為新會話但可能產(chǎn)生邏輯錯誤。通過以上這些步驟你就能在TongHttpServer上穩(wěn)健地部署和管理基于Session親和的有狀態(tài)Web服務(wù)集群。這套機制看似簡單卻是構(gòu)建高可用、可擴展Web應(yīng)用架構(gòu)的重要基石之一。