Nginx集群并发冲突需分层设防：一、用proxy_cache_lock消除缓存回源竞争；二、静态资源路径严格隔离；三、用limit_req/limit_conn控制请求洪峰；四、后端写操作依赖数据库原子保障。
处理 Nginx 集群中的并发访问冲突，关键不是让 Nginx 去“协调业务逻辑”，而是分层设防：在请求入口、缓存层、静态资源路由和后端协同四个层面做隔离与控制。冲突往往不是 Nginx 自身产生，而是配置不当或缺乏统一约束导致的资源错配、缓存覆盖或写入竞争。
一、用 proxy_cache_lock 消除缓存回源竞争
当多个请求同时命中未缓存的热点 URL，Nginx 默认可能触发多次后端回源，造成重复计算、响应不一致甚至缓存内容被部分覆盖。
- 启用 proxy_cache_lock on;：只允许首个未命中缓存的请求回源，其余请求等待该缓存生成完成后再读取
- 搭配 proxy_cache_lock_timeout 5s; 防止锁长期阻塞，再加 proxy_cache_lock_age 1s; 控制锁释放时机
- 确保 proxy_cache_path 所在目录权限正确，且不被外部脚本（如定时清理）干扰
二、静态资源路径必须严格隔离
多个后端服务共用同一域名时，若都使用 /static/ 路径，Nginx 无法区分归属，容易把 A 服务的 CSS 请求转发给 B 服务，导致样式丢失或 404。
- 每个后端服务配置独立静态前缀，例如 Flask A 用 /app1/static/，Flask B 用 /app2/static/
- Nginx 中为每个前缀单独定义 location 块，直接 alias 到对应物理路径，不经过 proxy_pass
- 避免所有服务共享全局 /static/；后端模板生成链接时也必须带前缀，不能依赖默认 static_url_path
三、通过限流模块控制请求洪峰
真正的并发冲突常源于突发流量压垮后端，而非 Nginx 本身。需在入口层主动削峰。
- 用 limit_req_zone 按 IP 或接口维度限速，例如 rate=10r/s + burst=20 nodelay，适应瞬时波动
- 用 limit_conn_zone 限制单个客户端并发连接数，防止恶意长连接耗尽 worker_connections
- 注意：limit_req 是请求速率控制（QPS），limit_conn 是连接数控制（并发数），二者互补不可替代
四、后端写操作必须依赖数据库原子保障
Nginx 不参与业务逻辑，但集群下多实例共用数据库时，“先查后插”类逻辑极易因时间窗口导致重复写入（如重复下单、重复注册）。
- 在数据库关键字段（手机号、订单号等）上建立 UNIQUE 索引，这是最基础且最有效的防线
- PHP 等应用层捕获 MySQL 错误码 1062，统一返回“已存在”，而非静默忽略或重试
- 改用原子语句，如 INSERT ... ON DUPLICATE KEY UPDATE 或 INSERT ... ON CONFLICT DO NOTHING，把判断与写入合并为一条 SQL
- 高热场景（如秒杀）可引入 Redis 的 SETNX 占位或消息队列串行化，但需权衡延迟与一致性
