nginx 的 sticky 模块通过计算客户端 ip 或 cookie 的哈希值，将其映射到后端服务器组中的特定节点，从而实现 session 会话保持。具体做法是在 upstream 块中配置 sticky 指令并设置共享内存区域大小，这样 nginx 会将带有相同标识的请求定向到同一台后端服务器，确保用户状态不丢失。
如何配置 upstream 实现基于 IP 的粘性分配
要实现基于客户端 IP 的会话保持，需要在 Nginx 配置文件的 http 块内定义一个 upstream 组，并在其中加入 sticky 指令。该指令会自动在响应头中插入一个名为 SERVERID 的 Cookie，后续请求若携带此 Cookie 或源自相同 IP，Nginx 会将其路由至最初分配的服务器。配置时需指定共享内存的大小以存储这些映射关系，防止重启后数据丢失。
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_pool;
}
}
upstream backend_pool {
sticky share=32 name=my_sticky;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
上述配置中，share=32 表示使用 32MB 的共享内存来存储会话映射表。name=my_sticky 用于标识该粘性会话组。当第一个请求到达时，Nginx 根据负载均衡算法（默认轮询）选择一台服务器，比如 192.168.1.10，并在返回的 HTTP 响应头中添加 Set-Cookie: SERVERID=xxx。客户端浏览器保存该 Cookie，后续请求自动带上它，Nginx 解析 Cookie 后将请求转发给 192.168.1.10，从而保持会话一致性。
如何自定义 Cookie 名称与路径以适应多应用部署
在多应用共用同一个 Nginx 实例的场景下，默认的 SERVERID Cookie 可能会发生冲突。可以通过 sticky 指令的 domain、path 和 mode 参数来自定义 Cookie 的行为。例如，设置不同的 path 可以隔离不同应用的会话，而修改 mode 可以控制是否依赖客户端发送 Cookie 还是仅依赖 IP。
upstream app_a_pool {
sticky domain=.example.com path=/app_a mode=insert;
server 10.0.0.1:8080;
server 10.0.0.2:8080;
}
upstream app_b_pool {
sticky domain=.example.com path=/app_b mode=insert;
server 10.0.0.3:8080;
server 10.0.0.4:8080;
}
在上面的配置中，app_a_pool 和 app_b_pool 分别对应不同的应用路径。通过设置 path=/app_a 和 path=/app_b，Nginx 生成的 Cookie 将仅在各自的路径下有效，避免了跨应用干扰。mode=insert 表示如果客户端未发送相关 Cookie，Nginx 会在响应中插入新的 Cookie；如果已存在，则更新其值。这种配置确保了即使多个应用共享域名，它们的会话保持也是独立且互不影响的。
当后端服务器宕机时 Sticky 模块如何处理故障转移
当被选中的后端服务器宕机或不可用时，sticky 模块会根据配置的 fail_timeout 和 max_fails 机制进行故障转移。此时，Nginx 会将该服务器标记为暂时不可用，并将请求重新分配给其他健康的后端节点。同时，原有的 Cookie 中的服务器标识可能失效，Nginx 会生成新的 SERVERID 并返回给客户端，确保后续请求能正确路由到新分配的服务器。
