应选 $uri 而非 $request_uri，因 $uri 是重写后无参数的标准路径（如 /api/orders），保障路径级会话一致性；$request_uri 含查询参数，易致哈希失稳。
要用 upstream 块实现基于 URL 路径的会话一致性，核心是用 hash $uri（或 hash $request_uri）指令替代默认轮询，让相同路径的请求始终落到同一台后端服务器。
为什么选 $uri 而不是 $request_uri？
$uri 是重写后、不带参数的标准路径（如 /api/orders），适合按业务路径做一致性分发；
$request_uri 包含全部查询参数（如 /api/orders?id=123&status=pending），参数稍有变化就会导致哈希值不同，破坏一致性。
所以对“路径级会话保持”——比如 /static/、/upload/、/product/1001 这类固定资源或接口——优先用 $uri。
基础配置写法
在 upstream 块中启用 hash，并指定 key：
- 定义 upstream 组，加入
hash $uri consistent;（加consistent可减少服务器增减时的重映射） - server 行无需额外标记，Nginx 自动按 $uri 的哈希值分配
- 确保后端服务对同一路径的处理逻辑幂等，避免因路径重复访问引发副作用
示例：
upstream backend_by_path {
hash $uri consistent;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
适用场景与注意事项
这种策略特别适合以下情况：
- 静态资源服务：/images/、/css/、/js/ 等路径请求固定由某台 CDN 边缘节点或文件服务器响应，提升缓存命中率
- 分片上传合并：用户上传 /upload/chunk/1001-001 → /upload/chunk/1001-005，所有 chunk 都落在同一台服务器，便于本地合并
- 读多写少的热点数据接口：如 /product/12345，高频读请求被稳定路由，减轻数据库压力
注意点：
- 不适用于需要用户级会话（如登录态）的场景——这时应选
ip_hash或 cookie-based sticky - 若路径中含动态 ID 但 ID 分布极不均匀（如 90% 请求集中在 /product/1），会导致某台后端过载
- 需配合健康检查（如
max_fails=2 fail_timeout=30s），保证故障节点自动剔除，避免哈希失效
进阶：按 URL 参数做更细粒度控制
如果必须依赖某个参数（如商品编号 ?sku=ABC123），可用 map 提取后再 hash：
- 先用
map $request_uri $sku_key解析出 sku 值 - 再在 upstream 中写
hash $sku_key consistent; - 这样即使完整 URI 不同（如带 utm_source），只要 sku 一致，就路由到同一台机器
该方式更适合缓存穿透防护或灰度发布中的流量隔离。
