debian缓存与CDN缓存如何配合

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 与 日志分析 做容量与异常预警。