nginx 本身不支持分布式缓存集群原生架构，需结合 keepalived 实现 vip 高可用，并将分布式缓存交由 redis cluster 等专用中间件承载，nginx 仅作反向代理与负载分发，避免 proxy_cache 孤岛问题。
Nginx 本身不支持分布式缓存集群原生架构，但可通过组合 Nginx + Keepalived + 外部缓存层（如 Redis、Memcached 或多节点 Nginx proxy_cache 共享存储）实现具备高可用与缓存能力的负载集群。关键在于：Keepalived 负责 VIP 高可用与故障漂移，Nginx 承担反向代理、负载分发与本地缓存，而“分布式缓存”需额外设计共享机制，不能仅靠单机 proxy_cache 实现真正分布。
以下聚焦实际可落地的方案要点：
Nginx 本地缓存需统一后端标识，避免缓存不一致
Nginx 的 proxy_cache 是本地磁盘/内存缓存，每台 Nginx 实例独立维护。若直接部署多台带 cache 的 Nginx 并用 Keepalived 做主备或双活，会出现：
- 同一请求在不同节点命中不同缓存（内容可能不一致）
- 缓存更新无法同步，导致脏数据
✅ 正确做法：
- 使用一致哈希（
hash $request_uri consistent;）或基于用户 ID / 参数的 key 拆分策略，让相同请求始终落到同一台 Nginx 节点 - 或关闭各节点的
proxy_cache，改由上游统一缓存服务（如 Redis）处理，Nginx 仅作透传代理
Keepalived 确保入口 VIP 永不中断，但不解决缓存同步
Keepalived 的核心作用是 VRRP 协议下 VIP 的自动接管。典型配置中：
- 主节点（priority 100）持有 VIP（如 192.168.1.100），运行 Nginx
- 备节点（priority 90）监听主节点健康状态（通过
check_script或 HTTP GET 接口） - 一旦主节点 Nginx 进程异常或机器宕机，VIP 秒级漂移到备节点
⚠️ 注意：
- Keepalived 默认只检测进程存活或端口连通性，不感知 Nginx 缓存是否有效或后端响应是否正确
- 若需缓存层健康联动（例如 Redis 不可用时降级），必须自定义检查脚本并集成进
vrrp_script
真正的“分布式缓存”建议交由专用中间件承载
把缓存逻辑从 Nginx 卸载，更可控、可扩展：
- 所有 Nginx 节点统一将读请求转发至 Redis Cluster（或 Codis / Tendis）
- 写请求走业务逻辑层，主动失效或更新缓存
- Nginx 可配合
redis2-nginx-module或lua-resty-redis实现直连 Redis，减少跳转 - 示例 Lua 片段（简化）：
location /api/data { content_by_lua_block { local red = redis:new() red:set_timeout(1000) local ok, err = red:connect("192.168.1.200", 6379) if not ok then ngx.exit(502) end local res, err = red:get(ngx.var.arg_key) if res then ngx.say(res) else ngx.exec("/backend") end } }
部署结构推荐：三层次解耦
| 层级 | 组件 | 职责 | 数量建议 |
|---|---|---|---|
| 接入层 | Nginx + Keepalived | 接收流量、SSL 终结、负载分发、简单缓存兜底 | 至少 2 台（主备或双主） |
| 缓存层 | Redis Cluster / Memcached Pool | 统一缓存存储、过期管理、高并发读写 | 3 节点起步（含哨兵或 cluster 模式） |
| 应用层 | 后端 Web Server（Tomcat/Nginx/Go） | 业务处理、缓存写入、数据库交互 | 按压测结果水平扩展 |
这样既发挥 Nginx 轻量高效的优势，又规避其缓存孤岛问题，同时 Keepalived 专注保障入口 SLA，整体更符合生产环境稳定性要求。
