主动失效Nginx缓存需由业务系统在数据库更新后调用proxy_cache_purge接口，前提为启用该模块、正确定义cache_zone与cache_key，并严格限制purge接口访问权限，辅以短缓存时间与后台更新机制防雪崩。
数据库更新时主动通知 Nginx 失效缓存，核心思路不是让数据库“直接通知”Nginx，而是由业务系统（应用层）在完成数据库写操作后，同步触发 Nginx 的缓存清理动作。Nginx 本身不监听数据库变更，必须通过外部显式调用 purge 接口来实现主动失效。
确保 Nginx 已启用并配置 proxy_cache_purge 模块
该模块非 Nginx 官方默认内置，需确认已编译安装（如使用 OpenResty、Tengine，或自行添加 --with-http_proxy_cache_purge_module）。未启用则所有 purge 请求都会返回 404 或 405 错误。
- 检查是否加载：运行
nginx -V 2>&1 | grep -o with-http_proxy_cache_purge_module，有输出即表示支持 - 定义缓存区：在
http块中配置proxy_cache_path，例如：proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off; - 启用缓存：在对应
location中指定proxy_cache my_cache，并严格设置proxy_cache_key（后续 purge 必须完全复现该 key）
在业务逻辑中嵌入缓存清理调用
数据库更新成功后，立即向 Nginx 发起一次 purge 请求，精准清除受影响资源的缓存项。这是最可控、低延迟的方式。
- 例如用户资料更新后，调用：
curl -X GET "https://api.example.com/purge/users/123" - 关键点在于 URL 路径与
proxy_cache_key生成逻辑一致。若 key 包含协议、方法、host 和 URI，则 purge 请求的 key 应为httpsGETapi.example.com/users/123 - 建议封装成统一工具函数，避免硬编码；生产环境应加入重试和错误日志，防止 purge 失败导致脏缓存残留
配置安全的 purge 接口
不能将 purge 功能暴露给公网，必须限制访问来源，通常只允许本机或内部部署服务调用。
- 在 server 块内添加专用 location：
location ~ /purge(/.*) {<br> allow 127.0.0.1;<br> allow 10.0.10.5; # CI/CD 服务器 IP<br> deny all;<br> proxy_cache_purge my_cache $scheme$request_method$host$1;<br>} - 注意正则捕获
$1与实际请求路径的对应关系；若需支持带查询参数的清理（如/purge/article?id=100），需在proxy_cache_key中包含$args，并在 purge 行中补上$is_args$args
补充策略：结合自动过期与后台更新防雪崩
主动 purge 是首选，但不能完全替代合理的时间策略。建议叠加以下配置增强鲁棒性：
- 设置较短的
proxy_cache_valid（如 200 响应缓存 5–10 分钟），避免 purge 失败时长期滞留旧数据 - 开启
proxy_cache_background_update on：缓存过期后，Nginx 在后台静默拉取新内容，前台仍返回旧缓存，用户无感知 - 配合
inactive=60m自动清理长期未访问的缓存文件，防止磁盘耗尽
