从浏览器HTTP缓存、Nginx中间层缓存到Redis应用缓存，逐级拦截重复请求，让后端数据库只处理真正需要计算的数据。 如果只在某一层做缓存，比如只配了Redis却不管浏览器缓存，整体性能提升会打折扣，还可能白白浪费服务器资源，下面按场景拆解配置方法。
缓存配置前先想清楚：你的服务器在缓存什么
不同业务的缓存配置方案差异很大,静态图片、视频文件和动态API接口的缓存策略完全不同，盲目套模板容易出问题。
按数据类型划分缓存策略
先明确服务器上跑的流量属于哪一类,再决定配置方向。
- 静态资源：CSS、JS、图片，变化频率低，适合加长浏览器缓存和CDN缓存。
- 动态接口：用户登录信息、订单数据，包含个性化内容，通常只做Redis缓存，不经过HTTP层缓存。
- 半动态数据：文章列表、商品信息，所有人看到的内容一样，但数据来自数据库，适合用Nginx缓存或Redis缓存。
行业共识认为,缓存分层越靠近用户，性能收益越明显，浏览器缓存命中一次，服务器连请求都看不到；CDN缓存命中一次，源服务器也省了一次流量。
缓存时长设置原则
缓存时间设置太短,大量请求仍然落到后端，服务器压力降不下来；设置太长，用户看到过期内容的概率增加。
- 带版本号的静态资源：缓存时间可以设置到30天以上，因为文件更新时URL会变。
- 不带版本号的HTML页面：缓存时间多数情况下控制在几分钟到几小时，兼顾时效性和性能。
- 视频分片文件：缓存到24小时以上，同时依靠刷新机制在源文件更新时主动清理。
视频服务器缓存配置怎么做：一个具体落地场景
视频网站的缓存配置比普通网站复杂,因为视频文件体积大、并发高、回源成本也高，国内不少视频站把MP4切片成HLS协议播放，目的就是为了提高缓存命中率。
流媒体缓存策略
视频服务器配置缓存的第一个动作,是在Web服务器层开启缓存响应头，以Nginx为例，在location块中加入以下配置：
location /videos/ {
add_header Cache-Control "public, max-age=86400";
add_header ETag "";
expires 24h;
}这里的关键操作有两个：
- Cache-Control设为public，允许CDN和浏览器都缓存视频文件。
- expires设24小时，避免频繁回源消耗源站带宽。
CDN缓存与服务器带宽成本
视频流量走源服务器直出,带宽费用会迅速上升，多数视频站会接入CDN，把视频分片推到边缘节点，这里涉及“服务器缓存配置价格”的现实问题：不加CDN，缓存配置得再好，源服务器的出口带宽也是瓶颈；加了CDN，每次回源产生的流量费用同样需要控制。
在CDN控制台配置缓存规则时,视频分片路径通常设置一个较长时长：
| 路径类型 | 缓存时长 | 回源优先级 |
|---|---|---|
| HLS视频分片（.ts） | 24小时 | 低，优先读边缘节点 |
| 视频封面图 | 30天 | 低 |
| 播放器API接口 | 5分钟 | 中 |
| 用户登录鉴权接口 | 不缓存 | 高，必须回源 |
视频服务器缓存配置中较容易忽略的一个点是回源Host设置，CDN回源时如果Host不对，源站返回404，CDN会把这个404缓存下来，导致视频大面积无法播放，配完后，建议用curl测试一下源站响应状态码，确认是200再放量。
切片还是整文件缓存
MP4格式的整文件缓存对CDN友好,但拖动进度条时回源效率不如HLS切片，近年来，HLS流媒体协议在web端和移动端的兼容性已经很好，采用TS切片方案的站点明显增多，切片缩小了单个缓存对象的体积，边缘节点缓存压力更小，命中率也更高。
Nginx缓存配置教程：HTTPS下静态资源缓存怎么配
HTTPS协议下,缓存配置要注意HTTP响应头仍然通过明文HTTP传给客户端，只是传输层加密，所以HTTP缓存机制本身不受影响。
静态资源缓存控制
在Nginx中,给静态资源单独设置location块，比全局配置更灵活：
location ~ .(js|css|png|jpg|webp)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}这里immutable的作用是告诉浏览器：这个文件在有效期内绝对不会变化，不需要每次刷新页面时发条件请求验证，能省掉一部分请求往返。
动态请求用proxy_cache做缓存
如果服务器上的动态页面请求量大,例如商品详情页没有包含个性化信息，可以用Nginx的proxy_cache缓存整个页面：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=10g inactive=60m; location /product/ { proxy_cache mycache; proxy_cache_valid 200 10m; proxy_pass http://backend; add_header X-Proxy-Cache $upstream_cache_status; }
加X-Proxy-Cache响应头是排查Nginx缓存命中的实用技巧，客户端通过响应头即可确认缓存是否命中，HIT表示命中，MISS表示未命中，不少运维人员说，这个头加上之后，缓存配置就没那么玄学了。
HTTPS连接复用与缓存的关系
启用HTTPS后,浏览器和服务器之间要完成TLS握手，每次新连接的开销比HTTP大，Nginx默认开启HTTP/2后，同一连接可以并发请求多个资源，配合长缓存时间，资源第二次加载直接从本地缓存读取，不需要建立新连接，动作顺序上，先打开HTTP/2，再配合静态资源长缓存，整体加载速度会比HTTP协议快不少。
数据库查询缓存与Redis应用缓存配置
HTTP层缓存负责挡请求,应用层缓存负责挡数据库查询。
Redis缓存常驻内存的配置参数
Redis是配置缓存的主力工具,它的关键配置文件redis.conf里，有几个参数必须根据服务器内存调整：
maxmemory 2gb
maxmemory-policy allkeys-lrumaxmemory决定了Redis最多能用多少内存，maxmemory-policy设成allkeys-lru，表示内存满时优先淘汰最久没被访问的键。
多数云服务器默认不开启swap,如果Redis占用内存超过系统物理内存，会直接触发OOM，Redis进程被系统杀掉，所以内存上限建议低于服务器物理内存，留出系统运行余量。
防缓存穿透和缓存雪崩
Redis缓存配置完成后,要额外处理两个问题：
- 缓存穿透：请求查的数据在数据库里不存在，每次请求都绕过缓存直奔数据库，解决办法是把空结果也缓存一下，设置较短的过期时间（如60秒）。
- 缓存雪崩：大量缓存键在同一时间过期，请求同时打到数据库，解决办法是给过期时间加一个随机值，错开失效时间点。
业内专家指出,Redis在生产环境宕机最常见的原因是内存耗尽和持久化阻塞，配置阶段就要把这两个问题规避掉。
缓存配置里的三个常见坑
缓存配置不光是加响应头,以下三个问题需要单独处理。
缓存与数据库数据不一致
缓存数据总是存在某个时间点比数据库旧的,能接受多旧，决定缓存时间多长。
- 用户昵称、头像：缓存5分钟，问题不大。
- 限时折扣价格：缓存1分钟，可能导致部分用户看到旧价格。
- 库存数量：尽量不缓存，或使用Redis原子操作保证实时性。
刷新缓存的自动化
视频拍摄完成后重新转码,原来的TS文件已经变了，但CDN和Nginx缓存里还是旧文件，用户刷新多次仍然看到旧内容，这时候需要主动刷新。
HLS协议下有一个技巧：切片文件名中带上版本号或时间戳，转码后文件名变化，请求自然落到新分片，绕开旧缓存，这是Nginx缓存配置里简单有效的方案。
验证缓存是否生效
配置完成后,用命令行直接验证最可靠。
curl -I https://你的域名/static/app.js关注响应头中的Cache-Control、Expires、Age字段，如果Age在增长，说明请求命中了缓存。
对于Redis,使用redis-cli monitor动态查看实时处理的命令，确认缓存键有被写入和读取。
服务器缓存配置常见问题解答
服务器缓存配置和CDN缓存有什么区别？
服务器缓存配置是在源服务器上部署Nginx、Redis等缓存组件，缓存内容存储在自有资源上；CDN缓存是在边缘节点缓存内容，用户就近读数据，前者控制力强，适合动态和私有数据；后者节点分布广，适合静态资源和视频分发的场景。
缓存配置做了却经常不生效怎么办？
先从最简单的场景测试：直接用curl查看响应头，若缺少缓存响应头，说明Nginx配置未生效，检查location块的匹配优先级；若Cache-Control正常但浏览器仍发请求，确认是否配置了ETag或Last-Modified，没有校验字段时常需要回源验证，另外检查是否同时存在多个Nginx层，比如负载均衡前面还有一层代理，两层都要配缓存。
视频服务器缓存配置后，播放进度条拖动变卡是什么原因？
播放器拖动进度条时会向服务器请求新的分片,如果这些分片不在缓存中，CDN或源服务器要临时读取磁盘文件并返回，多数情况下是因为分片文件偏大，或者CDN缓存中未命中，解决方案是加小分片时长，如将TS切片设置为4秒到6秒，并确保分片文件的缓存规则没有被权限校验规则覆盖。
服务器缓存配置没有一套覆盖所有场景的万用模板,关键在于按数据类型、访问频率和业务容忍度调整每一层缓存策略，静态资源加长缓存、动态数据走Redis、视频分片依赖CDN，这三条主线理清之后，大部分服务器的缓存配置都能做得比较规整。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/583467.html
