负载均衡之——会话保持

会话保持（Session Persistence） 是理解负载均衡集群的一个核心概念，简单来说：它的作用是确保一个用户的多次请求，始终被发送到同一台后端服务器上。

一、为什么需要"会话保持"？

要理解会话保持，得先知道一个背景：HTTP 协议本身是无状态的。这意味着，如果没有特殊机制，Web 服务器并不会记得"你是谁"。

想象一下这个场景：

1. 你在一个购物网站把商品加入了购物车。
2. 你的请求被负载均衡器分发到了 服务器A。
3. 当你去结算时，请求可能被分发到了 服务器B。

因为服务器B上没有你的购物车信息，它会告诉你："你的购物车是空的！"------这显然是不可接受的。

会话保持的目的，就是为了解决这个问题。 它让负载均衡器"记住"了用户和服务器之间的绑定关系，确保属于同一个会话（Session）的所有请求，都发往同一个后端服务器进行处理。

二、会话保持的常见实现方式

在实际生产中，根据"记住"绑定关系的方式不同，主要有以下几种方案：

方式	工作原理	优点	缺点	类比
1. 源地址哈希 (Source IP Hash)	负载均衡器根据客户端的IP地址做哈希计算，同一IP的请求总是发往同一台服务器。	实现简单，无需修改应用配置。	当多个用户共享一个出口IP（如公司、学校）时，负载会严重不均；服务器宕机时，会话会丢失。	像按家庭住址分配社区医院，一个地址的人总去同一家。
2. Cookie 插入 (Cookie Insert)	负载均衡器在首次响应时，自动插入一个记录服务器ID的Cookie。客户端后续请求带上这个Cookie，LB就知道该发往哪台服务器。	精准控制，不受代理IP影响，配置灵活。	需要浏览器启用Cookie；外部用户无法直接看到后端服务器信息，排障稍复杂。	像给你发一张写着"去2号窗口"的号码牌。
3. 会话共享 (Session Sharing)	并非LB的功能，而是应用架构的改造 。所有后端服务器都将Session数据统一存储在一个共享位置，如 Redis 或 数据库。	高可用，任意一台服务器宕机，会话不会丢失，其他服务器可无缝接管。	架构复杂，需要改造应用代码或配置，且引入共享存储会带来网络延迟。	像所有医院共享同一个电子病历系统，你去哪家都能看到你的病历。

三、生产环境的最佳实践

结合你刚才了解的面试题，一个优秀的候选人会给出这样的建议：

• 中小型项目或简单场景 ：可以使用 Cookie插入 方式。它配置简单，是Nginx、Apache等主流负载均衡器都支持的成熟特性，能满足大部分需求。
• 企业级、高可用生产环境 ：强烈推荐"会话共享"方案 。
  • 为什么？ 因为源地址哈希或Cookie插入这类"粘性会话"存在一个致命缺陷：如果一台服务器宕机了，那台服务器上所有用户的会话都会丢失，用户会被强制登出。
  • 怎么做？ 通常采用 Redis 作为外部共享会话存储器 。应用服务器（如Tomcat）配置使用 Redis 来存取Session。这样，无论请求被负载均衡器发到哪个节点，都能从Redis中正确获取到用户的会话信息，实现了真正的无状态 和高可用。

总的来说，会话保持的本质，是在无状态的HTTP协议之上，模拟出"有状态"的用户体验。