解决Nginx高可用集群请求重复提交，核心是禁用非幂等请求（POST/PUT/DELETE）的自动重试，通过清理non_idempotent配置、隔离写操作流量、强制proxy_next_upstream off，并辅以后端幂等校验与DB唯一索引防护。
解决 Nginx 高可用集群中请求重复提交，核心是管住它的“自动重试”行为——不是所有请求都适合重发，尤其涉及创建、支付、删除等写操作时，一次重试就可能变成两次执行。关键不在后端防重，而在 Nginx 层精准拦截不该重试的请求。
关掉非幂等请求的自动重试
Nginx 默认对 POST、PUT、DELETE 这类非幂等方法不做重试，但一旦配置了 proxy_next_upstream non_idempotent，或使用了老版本（如 1.8.x 及更早），就可能意外触发重发。务必检查并清理这类配置：
- 确认 upstream 或 location 块中没有启用 non_idempotent
- 把 proxy_next_upstream 显式设为安全组合，例如：
proxy_next_upstream error timeout http_502 http_503 http_504;（排除 http_500 和 http_4xx） - 写操作接口统一用 POST/PUT，并避免在 Nginx 层做 500 级别重试
按语义控制重试开关
不同 HTTP 方法风险不同，不能一概而论：
- GET / HEAD：天然幂等，可保留重试，但建议限制总次数（proxy_next_upstream_tries 2）和总耗时（proxy_next_upstream_timeout 6s）
- POST / PUT / DELETE：默认禁止重试；若业务强依赖（如日志上报），必须由后端实现幂等（如透传 idempotency-key + 服务端去重），Nginx 不代劳
- 上传类请求（含 large body）禁用重试，避免多次传输造成带宽和磁盘压力
隔离写操作流量，避免混用代理规则
把下单、支付、发短信等关键写路径，和查询类流量彻底分开：
- 单独定义 upstream write_backend { ... }，不与 read_backend 共享节点
- 用明确的 path 匹配（如 location ^~ /api/order/）绑定专用 upstream，不使用泛匹配 server_name 或正则路由
- 在写路径 location 中强制加 proxy_next_upstream off;，从源头杜绝转发
加兜底防护，防止漏网之鱼
即使 Nginx 配置正确，前端误点、脚本异常、网络抖动仍可能导致重复请求抵达后端：
- 后端入口层校验 Idempotency-Key 请求头，相同 key 的请求直接返回上次结果（HTTP 200 + 原响应体）
- 对关键事务操作，数据库层加唯一索引（如订单号、交易流水号），靠 DB 拦截重复插入
- 短时缓存层（如 Redis）记录最近 5 分钟已处理的请求指纹（如 MD5(body+timestamp)），命中即拒绝
