Nginx缓存机制是什么

Nginx缓存机制概览

说到Nginx的缓存，其实可以把它理解为一个双层防御体系。第一层是服务端缓存，Nginx自己充当“中间仓库”，利用proxy_cache、fastcgi_cache这些模块，把上游服务器的响应结果存到本地磁盘。下次遇到相同请求，直接从这里发货，不仅大大减轻了后端服务器的压力，连首字节到达时间（TTFB）都能明显缩短。第二层则是客户端缓存，也就是我们常说的浏览器缓存，通过Cache-Control、ETag这些HTTP头，让浏览器自己去决定是强缓存还是协商缓存。

想知道服务端缓存到底有没有生效？关键要看$upstream_cache_status这个变量。它的返回值就像一份清晰的“体检报告”，HIT（命中）、MISS（未命中）、BYPASS（绕过）、EXPIRED（过期）……每一个状态都揭示了缓存系统的运行状况。

核心工作流程

这个“中间仓库”是怎么运作的呢？流程其实相当精妙：

• 接收请求并计算缓存键：首先，Nginx会给每个请求生成一个唯一的“身份证号”，也就是缓存键。默认是$scheme$proxy_host$request_uri这个组合，但你完全可以根据业务需要，用proxy_cache_key指令加入Cookie或特定参数来定制。
• 查找命中：有了键，Nginx会先去一个叫keys_zone的共享内存区域快速查一下。如果找到了有效条目，恭喜，直接命中返回；如果没找到，那就只能向上游服务器发起请求了。
• 存储与过期：从上游拿到响应后，Nginx会把它存起来。有效期怎么定？要么遵循配置的proxy_cache_valid规则，要么听源头服务器的，看它的Cache-Control或Expires头。存储时，文件会按类似levels=1:2这样的分层目录结构存放，海量文件管理起来就轻松多了。
• 淘汰与加载：仓库容量有限，当缓存总量超过max_size时，cache manager进程会启动，按照LRU（最近最少使用）策略清理旧缓存。另外，Nginx启动时，cache loader进程会把磁盘上已有的缓存元数据逐步加载到内存，避免一次性加载对系统造成冲击。
• 容错与并发：这里有两个很实用的设计。一是容错，可以配置在后台出错或超时时，返回旧的（stale）缓存内容，保证服务不中断；二是并发控制，对同一个未命中的请求，可以启用proxy_cache_lock，让第一个请求去回源，后面的请求等着，避免“惊群效应”把上游服务器压垮。

关键指令与典型配置

理论说完了，来看看具体怎么配置。一个典型的缓存配置大概是下面这个样子：

http {
    proxy_cache_path /var/cache/nginx
                     levels=1:2
                     keys_zone=my_cache:10m
                     max_size=10g
                     inactive=60m
                     use_temp_path=off;

    server {
        location / {
            proxy_cache my_cache;
            proxy_pass http://backend;
            proxy_cache_key "$host$request_uri$is_args$args";
            proxy_cache_valid 200 302 10m;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            proxy_cache_revalidate on;
            proxy_cache_min_uses 3;
            proxy_cache_lock on;
            add_header X-Proxy-Cache $upstream_cache_status;
        }
    }
}

这里面有几个要点值得拎出来说说：

• keys_zone只存放缓存键和元数据，大小要规划好，经验上1MB大概能存8000个键。max_size才是限制缓存数据总量的。inactive这个参数很有意思，它控制的是“一段时间没被访问”的缓存能保留多久，这和缓存过期是两码事。设置use_temp_path=off则能减少一次磁盘文件拷贝，提升效率。
• 功能指令各司其职：proxy_cache_use_stale提升可用性；proxy_cache_revalidate在缓存过期后，会用If-Modified-Since头去验证，节省带宽；proxy_cache_min_uses可以过滤掉那些只被访问一两次的“冷内容”；proxy_cache_lock则是前面提到的抑制并发回源的利器。
• 最后，通过add_header X-Proxy-Cache $upstream_cache_status这行配置，把缓存命中状态加到响应头里，无论是调试还是做监控，都一目了然。

缓存控制与绕过

缓存虽好，但不是什么内容都适合缓存，也不是所有时候都要走缓存。Nginx提供了一套细致的控制机制：

• 默认行为：Nginx默认只缓存GET和HEAD方法。如果响应里带了Set-Cookie，或者Cache-Control头是private、no-cache、no-store这类指令，Nginx会很识趣地不去缓存它。
• 覆盖与定制：当然，默认规则是可以被覆盖的。
  • 如果你想忽略源站的缓存头，自己说了算，可以用proxy_ignore_headers Cache-Control; proxy_ignore_headers Set-Cookie;，然后配合proxy_cache_valid来强制设定有效期。
  • 想缓存POST请求的结果？没问题，proxy_cache_methods GET HEAD POST;就能搞定。
  • 更精细的控制在于条件绕过：proxy_cache_bypass指令（比如检查特定cookie或URL参数）满足条件就直接回源，不读缓存；而proxy_no_cache指令满足条件则根本不把这次响应写入缓存。
• 人工清理：有时候我们需要主动清理某个缓存，比如文章更新后。Nginx标准模块不支持按URL精确删除，这时候就需要请出第三方模块ngx_cache_purge了，它允许你通过发送一个PURGE请求来清除匹配的缓存条目。

监控与最佳实践

配置上线了，怎么知道它工作得好不好？接下来就是监控和调优。

• 观测指标：核心就是前面反复提到的$upstream_cache_status。把它的值（HIT, MISS, EXPIRED…）记录到访问日志，或者通过响应头输出，你就能清晰地看到命中率、回源压力集中在哪，这是调优的第一步。
• 调参要点：几个关键参数的设置，直接决定了缓存系统的效能。
  • keys_zone大小要适中，太小影响查找效率，太大浪费内存；目录层级levels=1:2是经过验证的通用最佳实践。
  • max_size和inactive需要一起考虑，共同决定缓存容量和留存时间。再结合业务内容的更新频率，来设定proxy_cache_valid。
  • 对于可能突发大量请求未命中的场景，记得打开proxy_cache_lock。对于变化不频繁但需要验证的内容，开启proxy_cache_revalidate能有效节省带宽。
  • 最后，别忘了客户端缓存。对于静态资源，大胆设置长的Cache-Control: public, max-age；对于动态接口，则建议缩短缓存时间，或者配合ETag、Last-Modified使用协商缓存策略。