Debian缓存与CDN缓存的协同方案
一、分层缓存架构与职责
- 浏览器缓存：由源站通过 Cache-Control / Expires / ETag 等响应头控制，适合长期不变的静态资源（如带哈希指纹的 JS/CSS/图片）。
- CDN边缘缓存：靠近用户，承担静态资源与可缓存API的加速；通过 Cache-Control / 路径规则 / 目录/文件后缀 配置缓存策略，并支持按需 Purge/Refresh。
- 源站内部缓存：在 Nginx（反向代理/页面/对象缓存）、PHP（OPcache/APCu）、数据库（查询/缓冲池） 等层面减少回源与计算开销，提升TTFB与吞吐。
- 数据层缓存：对热点数据使用 Redis/Memcached 做对象缓存，降低数据库压力，并与应用层失效策略联动。
二、源站到CDN的缓存控制要点
- 静态资源（JS/CSS/图片/字体等）
- 使用长效缓存并结合内容指纹（如 filename.a1b2c3.js），设置：
- Nginx：location ~* .(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ { expires 30d; add_header Cache-Control “public, immutable”; }
- Apache：启用 mod_expires，ExpiresByType text/css “access plus 30 days” 等。
- 目的：让CDN与浏览器长期缓存，减少回源。
- HTML与动态内容
- 默认不缓存或短缓存：Cache-Control no-cache 或 max-age=60，必要时配合 ETag/Last-Modified 做协商缓存。
- 对可缓存的动态片段/接口，按业务设置 s-maxage（CDN可见）与 max-age（浏览器可见），如：Cache-Control “public, s-maxage=600, max-age=60”。
- 缓存键与Vary
- 统一 proxy_cache_key（如 $scheme$request_uri$is_args$args），避免参数顺序导致多份副本。
- 对压缩/设备差异使用 Vary: Accept-Encoding, User-Agent（按需）。
- 主动失效与版本化
- 发布新版本时，变更资源路径或文件名（指纹），或在CDN控制台 Purge 相关路径。
- 安全与合规
- 对敏感/隐私内容设置 Cache-Control: private 或 no-store；通过 CDN鉴权/Referer防盗链/Token 控制访问。
三、源站内部缓存配置示例（Nginx + PHP）
- Nginx反向代理/页面缓存（示例）
- 在 http 块定义共享缓存区：
- proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
- 在 server/location 中启用：
- proxy_cache my_cache;
- proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m;
- add_header X-Proxy-Cache $upstream_cache_status;（用于观测命中：HIT/MISS/EXPIRED）
- proxy_cache_bypass $http_cache_control;（便于调试时强制回源）
- proxy_cache_key $uri$is_args$args;
- 说明：上述策略让可缓存的响应在源站边缘先命中，未命中再回业务后端，减轻后端压力。
- PHP运行时缓存（OPcache/APCu）
- OPcache（php.ini 或 /etc/php/8.x/fpm/php.ini）：
- opcache.enable=1
- opcache.memory_consumption=128
- opcache.interned_strings_buffer=8
- opcache.max_accelerated_files=4000
- opcache.revalidate_freq=60
- APCu（用户态数据缓存）：
- extension=apcu.so
- apcu.enable=1
- apcu.shm_size=64M
- apcu.ttl=7200
- 目的：减少PHP编译与数据库查询，提升页面生成速度。
四、缓存一致性与失效策略
- 缓存预热
- 上线或大促前，按访问热度将热点数据/页面主动加载到 Redis 与 CDN（结合脚本/队列并行预热），降低首波回源冲击。
- 过期时间错峰
- 为同类Key设置 基础TTL + 随机抖动（如 90±10 分钟），避免“缓存雪崩”（大量Key同时失效导致数据库瞬时压力）。
- 击穿/穿透/雪崩的应对
- 击穿（热点Key过期）：对超热Key设置更长TTL或后台定时刷新；必要时用分布式锁控制重建并发。
- 穿透（查无此数据）：对空结果做短期 null 缓存（如 30–60秒），配合 布隆过滤器/白名单 拦截非法请求。
- 雪崩（大面积过期）：错峰过期、限流/降级、多级缓存（CDN → Nginx → Redis → DB）与快速扩容预案。
五、监控、验证与运维要点
- 观测指标
- 源站：Nginx 日志与 X-Proxy-Cache 命中率、回源QPS、后端P95/P99时延、5xx比例。
- CDN：边缘命中率、回源带宽/请求数、各状态码占比、Purge成功率。
- 数据层：Redis命中率、慢查询、连接数、内存使用。
- 发布与回滚
- 采用 文件名指纹 或 路径版本 发布；必要时灰度/金丝雀发布，出现问题快速回滚并 Purge 影响路径。
- 工具与自动化
- 使用 CDN厂商控制台/API 做缓存预热与批量失效；结合 Ansible/Salt 推送Nginx/OPcache配置；用 Prometheus/Grafana 与 日志分析 做容量与异常预警。
