半夜两点半我是被手机震醒的。群里连着刷了几十条报警用户一个接一个地反馈“明明登录着过一会儿又要重新登录”有个客户直接撂了狠话“你们系统是不是有Bug我不想用了”。我打开后台一看两台应用服务器的错误日志都在疯狂刷Session过期顿时就明白问题出在哪儿了——负载均衡是配了但Session一致性没跟上。这种场景对后端开发、运维、架构师来说都不陌生。服务器负载均衡本身就是个“看起来简单做起来一堆坑”的活尤其是当业务从单机变成多机之后路由策略和会话保持之间的关系会变得极其微妙。这篇文章我想把负载均衡的常见策略、每种策略适用的情况以及多节点下Session一致性的保障手段完整梳理一遍。不是教科书式的罗列而是按我实际验证过的顺序来讲能帮读者少走弯路。1. 一台服务器演变成一群服务器之后问题就开始变了1.1 从单机到集群性能解决了状态却“散”了最早的时候一个应用部署在一台服务器上用户请求进来应用在处理完业务逻辑后把临时状态放在当前进程的内存或Session里下一个请求再来还是这台机器状态自然还在。但流量涨起来之后单机扛不住我们就开始做集群。用负载均衡器把请求分发到多台应用服务器上比如Nginx后面挂两台Tomcat、三台Spring Boot实例。这样做的直接好处是吞吐量上去了、单点故障也缓解了。但代价也随之而来用户第一次请求落在A机器登录状态写进了A的Session第二次请求被负载均衡分到了B机器B的内存里没有这个Session于是用户被判定为“未登录”。这就是最经典的“Session丢失”问题。它不是程序逻辑出错而是状态存储跟请求路由的边界发生了变化旧方案在新架构下失效了。1.2 负载均衡不只是“分发请求”这么简单很多刚接触分布式系统的人把负载均衡理解成“随便哪台机器空闲就发到哪台”这个方向是对的但实际选型时远比这个复杂。负载均衡器常见分为四层L4和七层L7。四层工作在传输层按IP和端口转发性能极高比如LVS、F5七层工作在应用层能看懂HTTP协议可以按URL、Cookie做路由Nginx和HAProxy是典型代表。选择四层还是七层本身就会影响你能用哪些方式处理Session。四层转发快但看不到HTTP Cookie七层可以看到Cookie和Header能做更细腻的会话保持策略。这个区别在后面的Session方案里会反复涉及到。1.3 策略选择为什么是门“技术活”负载均衡策略决定了“下一个请求到底发给谁”而Session一致性问题恰恰就藏在这个“发给谁”的决定里。如果所有节点共享一套Session存储那策略选哪个都行如果Session还留在单机内存里那策略就变得非常关键——选错了就得靠用户反复重新登录来买单。所以策略选型和Session方案必须放在一起考虑而不是分开决策。这也是我写这篇文章的核心逻辑。2. 主流负载均衡策略逐一点评原理、适用场景与坑2.1 轮询与加权轮询最朴素也最容易被误用的策略轮询Round Robin就是按顺序把请求轮流分发到每台服务器第一次去A第二次去B第三次去C如此循环。这个策略实现最简单Nginx默认就是它。加权轮询Weighted Round Robin是在轮询基础上给每台服务器分配权重解决的是“新机器性能强、旧机器性能弱”这类异构集群的问题。比如配置upstream backend { server 10.0.0.1:8080 weight3; server 10.0.0.2:8080 weight1; }意味着10.0.0.1每接收3个请求10.0.0.2接收1个。但这里有个坑轮询是“无状态”的它根本不关心每台服务器的真实负载。如果某个请求特别耗时比如一次数据库慢查询拖了3秒在轮询模式下这个慢请求占住连接后后面的请求还是会被继续发往这台机器实际效果可能变成“一台累死、其他闲着”。所以轮询适合请求处理时间比较均匀的场景比如内部管理系统的普通增删改查。一旦请求耗时方差大就得考虑下面这类策略。2.2 最少连接与最短响应时间让“慢节点”现形最少连接Least Connections是Nginx的least_conn策略。它的思路很直接当前谁手里的活跃连接数最少就把新请求发给谁。upstream backend { least_conn; server 10.0.0.1:8080; server 10.0.0.2:8080; }这个策略对长连接、请求耗时不均的场景特别友好。比如WebSocket服务、文件上传下载这些请求占住连接的时间长按“连接数”来均衡比按“请求次数”更合理。但我实测中发现一个细节least_conn只看连接数不看CPU、内存。如果一台机器配置低每个请求都很重连接数不一定高但机器可能已经快挂了。这时候Nginx还是会把请求送过去直到这台机器彻底没响应。所以真正生产环境里更好的做法是采用“最短响应时间”类策略比如HAProxy里的balance hdr或基于应用侧指标做动态路由不过这些通常要配合注册中心或服务网格来实现。2.3 IP哈希与一致性哈希为Session问题埋下的伏笔IP哈希策略ip_hash的规则是对客户端IP做哈希计算把结果映射到某台服务器上同一个IP的请求始终落在同一台机器。upstream backend { ip_hash; server 10.0.0.1:8080; server 10.0.0.2:8080; }这是很多团队解决Session一致性问题的“第一反应”因为确实有效只要来源IP不变请求就一直打到同一台机器Session天然不丢。但它的缺陷同样明显。首先是负载不均一个公司或一个校园网出口通常是一个公网IP所有用户都会被哈希到同一台服务器其他机器闲着这台机器被压垮。其次是节点增减时映射关系会发生剧烈变化本来固定在A机器的用户可能被重新哈希到B机器Session还是会失效。一致性哈希Consistent Hashing是对IP哈希的改进核心思想是让节点变化时只有少部分请求受影响。实现上通过哈希环和一个虚拟节点机制在Nginx中可以通过hash $remote_addr consistent;来开启。不过同样没有根治负载不均的问题只是把影响范围缩小了。从我个人的经验看IP哈希和一致性哈希适合“小规模集群”“临时解决Session问题”这种过渡场景长期方案还是要看后面的集中式Session。2.4 策略对比与选型决策逻辑策略分发依据优点缺点适用场景轮询请求顺序实现简单、均衡性稳定不感知真实负载请求耗时均匀的业务加权轮询请求顺序权重适配异构机器权重难以动态调整机器配置不同的集群最少连接活跃连接数适配长连接不看CPU和内存WebSocket、文件传输IP哈希客户端IP天然会话保持负载不均、节点变动影响大小规模临时方案一致性哈希哈希环虚拟节点节点增删影响小仍无法根治不均缓存类业务路由选型时先问一个问题你的业务是无状态还是有状态无状态业务比如纯查询接口随便选轮询或最少连接都行。有状态业务比如登录态、购物车就必须同时考虑Session存储方案。如果一时半会改不动代码可以用IP哈希或Sticky过渡但一定要规划后续改造。3. Session一致性问题的根源状态从单机走向分布式3.1 Cookie与Session的分工到底谁在谁身上提到Session就绕不开Cookie这俩经常被混着说但职责完全不同。Session是服务端的概念它保存了用户会话相关的数据比如用户ID、权限、购物车内容。每个Session有一个唯一的SessionID作为标识。Cookie是客户端的概念它是浏览器保存的一小段数据。服务端在用户登录后会把SessionID写入Set-Cookie响应头浏览器存下来之后每次请求都带上这个Cookie一般叫JSESSIONID或自定义的Session ID服务端通过它找到对应的Session数据。打个比方Session是酒店的房卡系统里的登记信息Cookie是客人手里的房卡。客人每次来都要刷一下卡前台才能查到他的房间信息。3.2 多机部署后“登录态丢失”的完整链路现在我们还原一下开头那个凌晨的故障链路用户在登录页输入账号密码Nginx把请求转发到了A服务器。A服务器处理登录创建SessionSessionID为abc123并返回Set-Cookie: JSESSIONIDabc123。浏览器保存了cookie后续请求都会带上Cookie: JSESSIONIDabc123。Nginx再次收到请求但这次把它转发到了B服务器。B服务器拿着abc123在自己的内存里找Session找不到于是认为用户未登录踢回登录页。用户重试几次偶尔落在A服务器上又能正常访问表现就是“时好时坏动不动要重新登录”。问题的本质是Session数据被分散存储在多台机器的本地内存中而请求路由却不受这个限制。Cookie给了我们一把钥匙但钥匙没有规定必须去哪扇门开锁。3.3 为什么“重启大法”治不好这个问题遇到故障很多人的第一反应是重启应用服务器甚至重启Nginx。重启确实能清理掉一些异常状态比如内存泄漏。但在Session丢失的这个场景里重启治标不治本。因为问题的根因是“状态存储位置”和“请求路由策略”不一致只要Session还留在每台机器的本地内存里重启只是让所有Session全部清空用户需要全部重新登录。所以解决思路只有两条路要么让同一个用户每次请求都固定去同一台机器会话保持Session Sticky要么让所有机器共享同一个Session存储集中式Session。其中第二条路是真正能根治问题的方向。4. 四种Session一致性方案横评4.1 Session Sticky把用户绑死在固定节点Sticky的常见实现方式有两种。一种是基于IP的就是前面提到的ip_hash另一种是基于Cookie的比如Nginx通过sticky模块识别用户携带的Cookie把同一用户的请求固定转发到首次响应的那台机器。upstream backend { server 10.0.0.1:8080; server 10.0.0.2:8080; sticky cookie srv_id expires1h; }这个方案最直观改造量最小而且用户的体验确实稳定。但它的风险在于“单点绑定”——一旦A服务器宕机绑定在A上的所有用户请求被转发到BB内存里又没有Session于是这群用户集体“被下线”。如果其中有正在下单的、正在支付的场景后果就会比较严重。所以Sticky只适合对可用性要求不那么苛刻的业务。真要用的场景通常是节点数量少、且能做到每个节点都有完整Session备份的小规模集群。4.2 Session复制开箱即用但越用越心虚Session复制指的是应用服务器之间同步Session数据每个节点都保存一份全量Session。Tomcat自带Cluster配置通过组播或DeltaManager在节点间广播Session变化。好处是任何一台节点挂了另一台还有Session用户无感知。坏处也很明显所有Session都要在节点间同步数据量一大广播消息就是灾难集群规模超过3到5台性能下降就很明显。这种方式比较适合几十人用的内部系统或者老旧的Tomcat项目不便改动时的短期兜底。放生产环境的公网业务我不推荐尤其是有大用户量和高写入频率的场景网络和内存开销都会被拖垮。4.3 分布式Session集中存储目前最主流的方向集中存储的思路是把Session从应用服务器的本地内存里挪出来放到一个独立的、所有服务器都能访问的存储系统中比如Redis、Memcached或者数据库。应用服务器拿到SessionID后统一去Redis里查数据。Redis的读写速度足够快可以承担会话数据的读写压力又天然支持过期机制Session天然有TTL。这个方案的优点很明显应用节点无状态化Scale Out特别平滑任何一个节点宕机不影响其他节点的会话读取Session数据可以统一管理、统一回收。缺点是需要额外维护Redis集群并处理网络延迟和序列化开销。不过相对于它解决的痛点这些成本是值得的。现在Spring生态里有现成的Spring Session项目配置起来很方便后面我会具体展开。4.4 无状态化改造JWT换个思路绕开Session如果一个服务完全无状态那负载均衡器选什么策略都不重要了。JWTJSON Web Token就是一种典型的无状态认证方案登录时服务端生成一个带签名和过期时间的Token客户端保存它每次请求放在Header的Authorization里。服务端只需要验证签名不需要保存任何会话数据。JWT不是Session但它替代了Session的职责。好处是彻底解放了状态存储服务随便扩缩容坏处是Token难以主动失效用户被踢下线、修改密码后旧Token还有效这类问题处理起来比较麻烦需要引入黑名单或短有效期Refresh Token机制。所以这个方案适合“接口对接口”的通信比如后端服务之间的鉴权或者移动端App这种Session管理本身就不友好的场景。对于传统的浏览器Web应用还是得配合一定量的服务端状态来用。5. Redis共享Session实战从零到一5.1 Spring Session Redis的引入与基础配置如果你用的Java后端是Spring Boot做Redis共享Session的成本非常低。引入依赖dependency groupIdorg.springframework.session/groupId artifactIdspring-session-data-redis/artifactId /dependency然后写一个配置类开启Redis的HTTP Session支持Configuration EnableRedisHttpSession(maxInactiveIntervalInSeconds 1800) public class RedisSessionConfig { }这个配置的作用是Spring容器启动后原本由Tomcat管理的HttpSession会被重定向到Redis存储。应用代码里还是照常使用request.getSession()或者HttpSession来读写属性但底层数据已经存到Redis里了。还可以在application.yml里通过配置项来声明会话超时时间spring: session: timeout: 30m store-type: redis redis: host: 127.0.0.1 port: 6379这样应用代码不用大改Session就完成了从“本机内存”到“Redis集中存储”的迁移。5.2 序列化策略的选择JDK还是JSON这是最容易踩坑的地方。Spring Session默认使用JDK序列化也就是说存入Redis的Session对象是以Java序列化格式存储的。如果你只是“能用就行”默认配置可以跑通。但JDK序列化有几个问题存进去的Key和Value可读性差调试时完全看不出来内容是什么一旦实体类结构发生变化反序列化可能报错老数据全读不出来序列化体积偏大增加了Redis内存和网络传输开销。所以我建议直接改成JSON序列化。这里有两个选择Bean public RedisSerializerObject springSessionDefaultRedisSerializer() { return new GenericJackson2JsonRedisSerializer(); }GenericJackson2JsonRedisSerializer和GenericFastJsonRedisSerializer都是常见的方案。我个人更喜欢Jackson自带的这个因为不需要额外引入Fastjson依赖兼容性也更稳。但要注意一点改成JSON序列化后Session中存的对象必须要有默认构造函数以及对应的getter/setter否则反序列化时容易报类型映射错误。另外如果Session里存了自定义的复杂对象建议用JsonTypeInfo来控制类型信息不然Jackson无法知道反序列化成什么类。5.3 配置Redis主从与哨兵避免单点Redis共享Session解决了应用节点的问题但如果Redis本身挂了所有用户都会立刻“掉线”。因此Redis这一层必须做高可用最基本的配置是“一主两从三哨兵”。Linux下用Redis官方哨兵模式搭建时主从配置的核心参数是replicaof哨兵进程的监控配置类似sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000应用侧连接Redis时不要直连主节点而是连哨兵集群让客户端自动感知主从切换。Spring Boot配置里启用哨兵模式spring: redis: sentinel: master: mymaster nodes: - 10.0.0.10:26379 - 10.0.0.11:26379 - 10.0.0.12:26379上线前一定要做一次“主节点宕机”演练。我踩过一个很真实的坑哨兵能正常完成故障切换但Spring Boot的Jedis连接池不会主动刷新主节点地址导致切换后一段时间内应用还在连已宕机的旧主节点。解决方法是启用spring.redis.jedis.pool和timeout相关配置或者升级到Redisson客户端它自带拓扑刷新故障转移的感知速度好很多。5.4 压测验证登录态到底稳不稳配置做完只是第一步还要验证“换成Redis共享Session后请求落到任何一台节点都能识别登录态”。我的验证方法是部署两个Spring Boot实例Nginx把请求随机分发到这两台使用JMeter或curl脚本模拟登录记录返回的Cookie拿着同一个Cookie强制将请求打到另一台实例上比如直接在Nginx后加一个Host头指定某台服务器检查返回的接口数据是否仍是登录态。如果你用curl验证登录后的Cookie值大约长这样curl -c cookies.txt -X POST http://gateway/api/login -d usernametestpassword123456 curl -b cookies.txt http://gateway/api/user/info然后把cookies.txt里的Cookie带到另一台服务器curl -b cookies.txt --resolve gateway:80:10.0.0.2 http://gateway/api/user/info如果返回的依然是用户信息说明Session共享生效了。如果返回401或跳转登录就要回头检查两件事一是应用是不是同一个Redis实例二是序列化配置是否一致。这里的“一致”指的是所有应用节点必须用同一种序列化方式否则A机器用JDK序列化写入B机器用JSON反序列化去读等到用户请求被路由到B机器时照样会报错。6. 生产环境中的Session一致性进阶问题6.1 Session过期与Redis内存回收Session存入Redis时set命令会带上过期时间但很多人忽略了一个细节如果每次访问Session都重置TTL那在Redis里对应的Key会不断刷新有效期。Spring Session里的maxInactiveIntervalInSeconds决定的是session的闲置超时时间。用户持续操作时该session会被持续续期如果用户长时间不操作key才会自然过期被Redis淘汰。这里面有个生产环境的隐患如果业务里频繁往Session里写入大对象比如把一个列表对象整体塞进Session而用户量又很大Redis内存会涨得飞快。即使设置了过期时间短时间内的集中写入也可能导致内存不足触发Redis的淘汰策略把别的正常Key挤出内存。所以生产上要监控Redis的used_memory和expired_keys指标并给Session Key设置好统一的前缀例如spring:session:。通过命令批量查看Session Key的数量redis-cli keys spring:session:*如果发现Session数据异常庞大就要审查代码里到底往Session里塞了什么东西。很多情况下用户信息只需要存一个ID其他都走数据库查询就行。6.2 秒杀与订单过期场景里的Session联动热词里提到的“订单过期了怎么办”“秒杀 服务熔断和降级”都是真实业务里的经典问题这些和Session也有关系。秒杀场景中用户需要在极短时间内完成抢购但下单、支付是异步流程。如果用户登录态过期或者请求被路由到不同节点导致会话数据不一致就会出现“抢到了但无法提交订单”的荒谬局面。Session统一放Redis后至少不会因为路由变化导致用户“被下线”。订单过期通常用Redis的过期Key加事件通知或延迟队列来处理。这里更稳妥的方式是在生成订单时写入订单数据到Redis设置TTL为15分钟同时用Redisson的DelayedQueue或RabbitMQ的延迟队列兜底定时任务再扫描数据库做最终复核。Session数据本身不应该承担订单状态存储的职责它只负责“用户登录态”和“临时业务上下文”。另一个关键点是秒杀接口要独立做限流和降级防止瞬时流量把Redis打挂。Nginx层可以做连接数限制应用层可以用Sentinel或Hystrix这类工具做熔断。一旦Redis响应变慢熔断器要能快速切开Redis依赖保证用户还能访问静态页面而不是整个服务雪崩。6.3 Session劫持与安全加固Session共享之后Key被集中放在Redis里安全面的重要性会变得更高。常见的一个攻击方式是Session Fixation攻击者在用户登录前塞一个SessionID给用户用户登录成功后服务端没有更换SessionID攻击者就能利用同一个SessionID冒充用户。防御手段很简单登录成功之后必须调用request.changeSessionId()强制更换SessionID。其次是Cookie的安全属性生产环境一定要给Session Cookie设置HttpOnly和SecureHttpOnly防止JavaScript读取Cookie减少XSS攻击导致SessionID泄露的风险Secure确保Cookie只在HTTPS连接中传输避免被明文抓包截获。如果服务做了HTTPS终结Nginx上要注意将Set-Cookie中的Secure标记正常透传或者通过配置统一加上安全属性。另外还要防止Session数据在Redis里被恶意篡改。Redis本身要有访问密码且只监听内网地址绝不暴露到公网。如果条件允许给Redis和业务网络做VLAN隔离或安全组隔离让Redis只对应用服务器网段开放端口。6.4 一套顺手的三层监控思路Session一致性改造完成后不搭监控就相当于裸奔。我习惯用三条链路去盯第一层是负载均衡层监控Nginx的连接数、upstream各节点的响应时间和错误率。第二层是应用层监控JVM内存、GC频率和每个应用节点的Session获取耗时。第三层是Redis层监控命中率、内存用量、过期Key数量和处理命令的QPS。对于Spring Boot应用我会在应用里暴露/actuator/health和/actuator/metrics接口让Prometheus定时抓取再配合Grafana展示规则配置。至于报警条件我比较常用的是三条Redis内存使用率超过70%持续5分钟单台应用节点的错误率超过1%Nginx upstream节点的健康检查连续失败3次。只要这三条不出问题Session一致性通常也不会出问题。有过一次凌晨被Session故障叫醒的教训之后我格外重视这些指标。我在实际项目里走了不少弯路才把这些理顺尤其是“序列化方式不一致导致偶发登录失败”和“Redis哨兵切换期间连接池不感知”这两个坑排查过程极度消磨耐心。后来我给自己定了一条原则负载均衡策略和Session方案永远放在一起设计先定状态存储再谈路由策略顺序反了后面就会一直补窟窿。如果正在读这篇文章的你正好在经历类似的故障优先检查“所有应用节点是否连的是同一个Redis”再用我上面给的curl验证步骤复现一次多半能快速定位。Session这个问题理论上并不难难的是把所有细节都打磨到位。
负载均衡策略与Session一致性：从原理到Redis实战
半夜两点半我是被手机震醒的。群里连着刷了几十条报警用户一个接一个地反馈“明明登录着过一会儿又要重新登录”有个客户直接撂了狠话“你们系统是不是有Bug我不想用了”。我打开后台一看两台应用服务器的错误日志都在疯狂刷Session过期顿时就明白问题出在哪儿了——负载均衡是配了但Session一致性没跟上。这种场景对后端开发、运维、架构师来说都不陌生。服务器负载均衡本身就是个“看起来简单做起来一堆坑”的活尤其是当业务从单机变成多机之后路由策略和会话保持之间的关系会变得极其微妙。这篇文章我想把负载均衡的常见策略、每种策略适用的情况以及多节点下Session一致性的保障手段完整梳理一遍。不是教科书式的罗列而是按我实际验证过的顺序来讲能帮读者少走弯路。1. 一台服务器演变成一群服务器之后问题就开始变了1.1 从单机到集群性能解决了状态却“散”了最早的时候一个应用部署在一台服务器上用户请求进来应用在处理完业务逻辑后把临时状态放在当前进程的内存或Session里下一个请求再来还是这台机器状态自然还在。但流量涨起来之后单机扛不住我们就开始做集群。用负载均衡器把请求分发到多台应用服务器上比如Nginx后面挂两台Tomcat、三台Spring Boot实例。这样做的直接好处是吞吐量上去了、单点故障也缓解了。但代价也随之而来用户第一次请求落在A机器登录状态写进了A的Session第二次请求被负载均衡分到了B机器B的内存里没有这个Session于是用户被判定为“未登录”。这就是最经典的“Session丢失”问题。它不是程序逻辑出错而是状态存储跟请求路由的边界发生了变化旧方案在新架构下失效了。1.2 负载均衡不只是“分发请求”这么简单很多刚接触分布式系统的人把负载均衡理解成“随便哪台机器空闲就发到哪台”这个方向是对的但实际选型时远比这个复杂。负载均衡器常见分为四层L4和七层L7。四层工作在传输层按IP和端口转发性能极高比如LVS、F5七层工作在应用层能看懂HTTP协议可以按URL、Cookie做路由Nginx和HAProxy是典型代表。选择四层还是七层本身就会影响你能用哪些方式处理Session。四层转发快但看不到HTTP Cookie七层可以看到Cookie和Header能做更细腻的会话保持策略。这个区别在后面的Session方案里会反复涉及到。1.3 策略选择为什么是门“技术活”负载均衡策略决定了“下一个请求到底发给谁”而Session一致性问题恰恰就藏在这个“发给谁”的决定里。如果所有节点共享一套Session存储那策略选哪个都行如果Session还留在单机内存里那策略就变得非常关键——选错了就得靠用户反复重新登录来买单。所以策略选型和Session方案必须放在一起考虑而不是分开决策。这也是我写这篇文章的核心逻辑。2. 主流负载均衡策略逐一点评原理、适用场景与坑2.1 轮询与加权轮询最朴素也最容易被误用的策略轮询Round Robin就是按顺序把请求轮流分发到每台服务器第一次去A第二次去B第三次去C如此循环。这个策略实现最简单Nginx默认就是它。加权轮询Weighted Round Robin是在轮询基础上给每台服务器分配权重解决的是“新机器性能强、旧机器性能弱”这类异构集群的问题。比如配置upstream backend { server 10.0.0.1:8080 weight3; server 10.0.0.2:8080 weight1; }意味着10.0.0.1每接收3个请求10.0.0.2接收1个。但这里有个坑轮询是“无状态”的它根本不关心每台服务器的真实负载。如果某个请求特别耗时比如一次数据库慢查询拖了3秒在轮询模式下这个慢请求占住连接后后面的请求还是会被继续发往这台机器实际效果可能变成“一台累死、其他闲着”。所以轮询适合请求处理时间比较均匀的场景比如内部管理系统的普通增删改查。一旦请求耗时方差大就得考虑下面这类策略。2.2 最少连接与最短响应时间让“慢节点”现形最少连接Least Connections是Nginx的least_conn策略。它的思路很直接当前谁手里的活跃连接数最少就把新请求发给谁。upstream backend { least_conn; server 10.0.0.1:8080; server 10.0.0.2:8080; }这个策略对长连接、请求耗时不均的场景特别友好。比如WebSocket服务、文件上传下载这些请求占住连接的时间长按“连接数”来均衡比按“请求次数”更合理。但我实测中发现一个细节least_conn只看连接数不看CPU、内存。如果一台机器配置低每个请求都很重连接数不一定高但机器可能已经快挂了。这时候Nginx还是会把请求送过去直到这台机器彻底没响应。所以真正生产环境里更好的做法是采用“最短响应时间”类策略比如HAProxy里的balance hdr或基于应用侧指标做动态路由不过这些通常要配合注册中心或服务网格来实现。2.3 IP哈希与一致性哈希为Session问题埋下的伏笔IP哈希策略ip_hash的规则是对客户端IP做哈希计算把结果映射到某台服务器上同一个IP的请求始终落在同一台机器。upstream backend { ip_hash; server 10.0.0.1:8080; server 10.0.0.2:8080; }这是很多团队解决Session一致性问题的“第一反应”因为确实有效只要来源IP不变请求就一直打到同一台机器Session天然不丢。但它的缺陷同样明显。首先是负载不均一个公司或一个校园网出口通常是一个公网IP所有用户都会被哈希到同一台服务器其他机器闲着这台机器被压垮。其次是节点增减时映射关系会发生剧烈变化本来固定在A机器的用户可能被重新哈希到B机器Session还是会失效。一致性哈希Consistent Hashing是对IP哈希的改进核心思想是让节点变化时只有少部分请求受影响。实现上通过哈希环和一个虚拟节点机制在Nginx中可以通过hash $remote_addr consistent;来开启。不过同样没有根治负载不均的问题只是把影响范围缩小了。从我个人的经验看IP哈希和一致性哈希适合“小规模集群”“临时解决Session问题”这种过渡场景长期方案还是要看后面的集中式Session。2.4 策略对比与选型决策逻辑策略分发依据优点缺点适用场景轮询请求顺序实现简单、均衡性稳定不感知真实负载请求耗时均匀的业务加权轮询请求顺序权重适配异构机器权重难以动态调整机器配置不同的集群最少连接活跃连接数适配长连接不看CPU和内存WebSocket、文件传输IP哈希客户端IP天然会话保持负载不均、节点变动影响大小规模临时方案一致性哈希哈希环虚拟节点节点增删影响小仍无法根治不均缓存类业务路由选型时先问一个问题你的业务是无状态还是有状态无状态业务比如纯查询接口随便选轮询或最少连接都行。有状态业务比如登录态、购物车就必须同时考虑Session存储方案。如果一时半会改不动代码可以用IP哈希或Sticky过渡但一定要规划后续改造。3. Session一致性问题的根源状态从单机走向分布式3.1 Cookie与Session的分工到底谁在谁身上提到Session就绕不开Cookie这俩经常被混着说但职责完全不同。Session是服务端的概念它保存了用户会话相关的数据比如用户ID、权限、购物车内容。每个Session有一个唯一的SessionID作为标识。Cookie是客户端的概念它是浏览器保存的一小段数据。服务端在用户登录后会把SessionID写入Set-Cookie响应头浏览器存下来之后每次请求都带上这个Cookie一般叫JSESSIONID或自定义的Session ID服务端通过它找到对应的Session数据。打个比方Session是酒店的房卡系统里的登记信息Cookie是客人手里的房卡。客人每次来都要刷一下卡前台才能查到他的房间信息。3.2 多机部署后“登录态丢失”的完整链路现在我们还原一下开头那个凌晨的故障链路用户在登录页输入账号密码Nginx把请求转发到了A服务器。A服务器处理登录创建SessionSessionID为abc123并返回Set-Cookie: JSESSIONIDabc123。浏览器保存了cookie后续请求都会带上Cookie: JSESSIONIDabc123。Nginx再次收到请求但这次把它转发到了B服务器。B服务器拿着abc123在自己的内存里找Session找不到于是认为用户未登录踢回登录页。用户重试几次偶尔落在A服务器上又能正常访问表现就是“时好时坏动不动要重新登录”。问题的本质是Session数据被分散存储在多台机器的本地内存中而请求路由却不受这个限制。Cookie给了我们一把钥匙但钥匙没有规定必须去哪扇门开锁。3.3 为什么“重启大法”治不好这个问题遇到故障很多人的第一反应是重启应用服务器甚至重启Nginx。重启确实能清理掉一些异常状态比如内存泄漏。但在Session丢失的这个场景里重启治标不治本。因为问题的根因是“状态存储位置”和“请求路由策略”不一致只要Session还留在每台机器的本地内存里重启只是让所有Session全部清空用户需要全部重新登录。所以解决思路只有两条路要么让同一个用户每次请求都固定去同一台机器会话保持Session Sticky要么让所有机器共享同一个Session存储集中式Session。其中第二条路是真正能根治问题的方向。4. 四种Session一致性方案横评4.1 Session Sticky把用户绑死在固定节点Sticky的常见实现方式有两种。一种是基于IP的就是前面提到的ip_hash另一种是基于Cookie的比如Nginx通过sticky模块识别用户携带的Cookie把同一用户的请求固定转发到首次响应的那台机器。upstream backend { server 10.0.0.1:8080; server 10.0.0.2:8080; sticky cookie srv_id expires1h; }这个方案最直观改造量最小而且用户的体验确实稳定。但它的风险在于“单点绑定”——一旦A服务器宕机绑定在A上的所有用户请求被转发到BB内存里又没有Session于是这群用户集体“被下线”。如果其中有正在下单的、正在支付的场景后果就会比较严重。所以Sticky只适合对可用性要求不那么苛刻的业务。真要用的场景通常是节点数量少、且能做到每个节点都有完整Session备份的小规模集群。4.2 Session复制开箱即用但越用越心虚Session复制指的是应用服务器之间同步Session数据每个节点都保存一份全量Session。Tomcat自带Cluster配置通过组播或DeltaManager在节点间广播Session变化。好处是任何一台节点挂了另一台还有Session用户无感知。坏处也很明显所有Session都要在节点间同步数据量一大广播消息就是灾难集群规模超过3到5台性能下降就很明显。这种方式比较适合几十人用的内部系统或者老旧的Tomcat项目不便改动时的短期兜底。放生产环境的公网业务我不推荐尤其是有大用户量和高写入频率的场景网络和内存开销都会被拖垮。4.3 分布式Session集中存储目前最主流的方向集中存储的思路是把Session从应用服务器的本地内存里挪出来放到一个独立的、所有服务器都能访问的存储系统中比如Redis、Memcached或者数据库。应用服务器拿到SessionID后统一去Redis里查数据。Redis的读写速度足够快可以承担会话数据的读写压力又天然支持过期机制Session天然有TTL。这个方案的优点很明显应用节点无状态化Scale Out特别平滑任何一个节点宕机不影响其他节点的会话读取Session数据可以统一管理、统一回收。缺点是需要额外维护Redis集群并处理网络延迟和序列化开销。不过相对于它解决的痛点这些成本是值得的。现在Spring生态里有现成的Spring Session项目配置起来很方便后面我会具体展开。4.4 无状态化改造JWT换个思路绕开Session如果一个服务完全无状态那负载均衡器选什么策略都不重要了。JWTJSON Web Token就是一种典型的无状态认证方案登录时服务端生成一个带签名和过期时间的Token客户端保存它每次请求放在Header的Authorization里。服务端只需要验证签名不需要保存任何会话数据。JWT不是Session但它替代了Session的职责。好处是彻底解放了状态存储服务随便扩缩容坏处是Token难以主动失效用户被踢下线、修改密码后旧Token还有效这类问题处理起来比较麻烦需要引入黑名单或短有效期Refresh Token机制。所以这个方案适合“接口对接口”的通信比如后端服务之间的鉴权或者移动端App这种Session管理本身就不友好的场景。对于传统的浏览器Web应用还是得配合一定量的服务端状态来用。5. Redis共享Session实战从零到一5.1 Spring Session Redis的引入与基础配置如果你用的Java后端是Spring Boot做Redis共享Session的成本非常低。引入依赖dependency groupIdorg.springframework.session/groupId artifactIdspring-session-data-redis/artifactId /dependency然后写一个配置类开启Redis的HTTP Session支持Configuration EnableRedisHttpSession(maxInactiveIntervalInSeconds 1800) public class RedisSessionConfig { }这个配置的作用是Spring容器启动后原本由Tomcat管理的HttpSession会被重定向到Redis存储。应用代码里还是照常使用request.getSession()或者HttpSession来读写属性但底层数据已经存到Redis里了。还可以在application.yml里通过配置项来声明会话超时时间spring: session: timeout: 30m store-type: redis redis: host: 127.0.0.1 port: 6379这样应用代码不用大改Session就完成了从“本机内存”到“Redis集中存储”的迁移。5.2 序列化策略的选择JDK还是JSON这是最容易踩坑的地方。Spring Session默认使用JDK序列化也就是说存入Redis的Session对象是以Java序列化格式存储的。如果你只是“能用就行”默认配置可以跑通。但JDK序列化有几个问题存进去的Key和Value可读性差调试时完全看不出来内容是什么一旦实体类结构发生变化反序列化可能报错老数据全读不出来序列化体积偏大增加了Redis内存和网络传输开销。所以我建议直接改成JSON序列化。这里有两个选择Bean public RedisSerializerObject springSessionDefaultRedisSerializer() { return new GenericJackson2JsonRedisSerializer(); }GenericJackson2JsonRedisSerializer和GenericFastJsonRedisSerializer都是常见的方案。我个人更喜欢Jackson自带的这个因为不需要额外引入Fastjson依赖兼容性也更稳。但要注意一点改成JSON序列化后Session中存的对象必须要有默认构造函数以及对应的getter/setter否则反序列化时容易报类型映射错误。另外如果Session里存了自定义的复杂对象建议用JsonTypeInfo来控制类型信息不然Jackson无法知道反序列化成什么类。5.3 配置Redis主从与哨兵避免单点Redis共享Session解决了应用节点的问题但如果Redis本身挂了所有用户都会立刻“掉线”。因此Redis这一层必须做高可用最基本的配置是“一主两从三哨兵”。Linux下用Redis官方哨兵模式搭建时主从配置的核心参数是replicaof哨兵进程的监控配置类似sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 60000应用侧连接Redis时不要直连主节点而是连哨兵集群让客户端自动感知主从切换。Spring Boot配置里启用哨兵模式spring: redis: sentinel: master: mymaster nodes: - 10.0.0.10:26379 - 10.0.0.11:26379 - 10.0.0.12:26379上线前一定要做一次“主节点宕机”演练。我踩过一个很真实的坑哨兵能正常完成故障切换但Spring Boot的Jedis连接池不会主动刷新主节点地址导致切换后一段时间内应用还在连已宕机的旧主节点。解决方法是启用spring.redis.jedis.pool和timeout相关配置或者升级到Redisson客户端它自带拓扑刷新故障转移的感知速度好很多。5.4 压测验证登录态到底稳不稳配置做完只是第一步还要验证“换成Redis共享Session后请求落到任何一台节点都能识别登录态”。我的验证方法是部署两个Spring Boot实例Nginx把请求随机分发到这两台使用JMeter或curl脚本模拟登录记录返回的Cookie拿着同一个Cookie强制将请求打到另一台实例上比如直接在Nginx后加一个Host头指定某台服务器检查返回的接口数据是否仍是登录态。如果你用curl验证登录后的Cookie值大约长这样curl -c cookies.txt -X POST http://gateway/api/login -d usernametestpassword123456 curl -b cookies.txt http://gateway/api/user/info然后把cookies.txt里的Cookie带到另一台服务器curl -b cookies.txt --resolve gateway:80:10.0.0.2 http://gateway/api/user/info如果返回的依然是用户信息说明Session共享生效了。如果返回401或跳转登录就要回头检查两件事一是应用是不是同一个Redis实例二是序列化配置是否一致。这里的“一致”指的是所有应用节点必须用同一种序列化方式否则A机器用JDK序列化写入B机器用JSON反序列化去读等到用户请求被路由到B机器时照样会报错。6. 生产环境中的Session一致性进阶问题6.1 Session过期与Redis内存回收Session存入Redis时set命令会带上过期时间但很多人忽略了一个细节如果每次访问Session都重置TTL那在Redis里对应的Key会不断刷新有效期。Spring Session里的maxInactiveIntervalInSeconds决定的是session的闲置超时时间。用户持续操作时该session会被持续续期如果用户长时间不操作key才会自然过期被Redis淘汰。这里面有个生产环境的隐患如果业务里频繁往Session里写入大对象比如把一个列表对象整体塞进Session而用户量又很大Redis内存会涨得飞快。即使设置了过期时间短时间内的集中写入也可能导致内存不足触发Redis的淘汰策略把别的正常Key挤出内存。所以生产上要监控Redis的used_memory和expired_keys指标并给Session Key设置好统一的前缀例如spring:session:。通过命令批量查看Session Key的数量redis-cli keys spring:session:*如果发现Session数据异常庞大就要审查代码里到底往Session里塞了什么东西。很多情况下用户信息只需要存一个ID其他都走数据库查询就行。6.2 秒杀与订单过期场景里的Session联动热词里提到的“订单过期了怎么办”“秒杀 服务熔断和降级”都是真实业务里的经典问题这些和Session也有关系。秒杀场景中用户需要在极短时间内完成抢购但下单、支付是异步流程。如果用户登录态过期或者请求被路由到不同节点导致会话数据不一致就会出现“抢到了但无法提交订单”的荒谬局面。Session统一放Redis后至少不会因为路由变化导致用户“被下线”。订单过期通常用Redis的过期Key加事件通知或延迟队列来处理。这里更稳妥的方式是在生成订单时写入订单数据到Redis设置TTL为15分钟同时用Redisson的DelayedQueue或RabbitMQ的延迟队列兜底定时任务再扫描数据库做最终复核。Session数据本身不应该承担订单状态存储的职责它只负责“用户登录态”和“临时业务上下文”。另一个关键点是秒杀接口要独立做限流和降级防止瞬时流量把Redis打挂。Nginx层可以做连接数限制应用层可以用Sentinel或Hystrix这类工具做熔断。一旦Redis响应变慢熔断器要能快速切开Redis依赖保证用户还能访问静态页面而不是整个服务雪崩。6.3 Session劫持与安全加固Session共享之后Key被集中放在Redis里安全面的重要性会变得更高。常见的一个攻击方式是Session Fixation攻击者在用户登录前塞一个SessionID给用户用户登录成功后服务端没有更换SessionID攻击者就能利用同一个SessionID冒充用户。防御手段很简单登录成功之后必须调用request.changeSessionId()强制更换SessionID。其次是Cookie的安全属性生产环境一定要给Session Cookie设置HttpOnly和SecureHttpOnly防止JavaScript读取Cookie减少XSS攻击导致SessionID泄露的风险Secure确保Cookie只在HTTPS连接中传输避免被明文抓包截获。如果服务做了HTTPS终结Nginx上要注意将Set-Cookie中的Secure标记正常透传或者通过配置统一加上安全属性。另外还要防止Session数据在Redis里被恶意篡改。Redis本身要有访问密码且只监听内网地址绝不暴露到公网。如果条件允许给Redis和业务网络做VLAN隔离或安全组隔离让Redis只对应用服务器网段开放端口。6.4 一套顺手的三层监控思路Session一致性改造完成后不搭监控就相当于裸奔。我习惯用三条链路去盯第一层是负载均衡层监控Nginx的连接数、upstream各节点的响应时间和错误率。第二层是应用层监控JVM内存、GC频率和每个应用节点的Session获取耗时。第三层是Redis层监控命中率、内存用量、过期Key数量和处理命令的QPS。对于Spring Boot应用我会在应用里暴露/actuator/health和/actuator/metrics接口让Prometheus定时抓取再配合Grafana展示规则配置。至于报警条件我比较常用的是三条Redis内存使用率超过70%持续5分钟单台应用节点的错误率超过1%Nginx upstream节点的健康检查连续失败3次。只要这三条不出问题Session一致性通常也不会出问题。有过一次凌晨被Session故障叫醒的教训之后我格外重视这些指标。我在实际项目里走了不少弯路才把这些理顺尤其是“序列化方式不一致导致偶发登录失败”和“Redis哨兵切换期间连接池不感知”这两个坑排查过程极度消磨耐心。后来我给自己定了一条原则负载均衡策略和Session方案永远放在一起设计先定状态存储再谈路由策略顺序反了后面就会一直补窟窿。如果正在读这篇文章的你正好在经历类似的故障优先检查“所有应用节点是否连的是同一个Redis”再用我上面给的curl验证步骤复现一次多半能快速定位。Session这个问题理论上并不难难的是把所有细节都打磨到位。
