max_size是缓存层硬性限制磁盘容量的关键参数，只约束缓存数据本身，需结合淘汰机制、监控告警与入口过滤协同防护。
自建CDN节点的磁盘安全防护，核心不是“堆空间”，而是“控增长、防失控、可收敛”。max_size 是缓存层（如 Nginx proxy_cache、Varnish storage、或自研缓存模块）中用于硬性限制单个缓存区最大占用磁盘容量的关键参数，它直接决定节点在高并发回源或异常请求涌入时，是否会被缓存写满导致服务不可用甚至系统崩溃。
明确 max_size 的作用边界
它只约束缓存数据本身所占的磁盘空间，不包括日志、临时文件、系统文件等。若未配置，缓存可能无限增长；若设得过大，失去兜底意义；若设得太小，则频繁触发淘汰，降低命中率。关键是要与节点总磁盘容量、业务缓存特征（文件大小分布、热点集中度）、以及清理策略协同设计。
- 例如：1TB 系统盘，建议为缓存单独挂载 200GB 数据盘，max_size 设为 180GB，预留 20GB 给文件系统元数据及突发写入缓冲
- 若缓存对象以 1MB 以下小文件为主（如图片缩略图），需注意 inode 耗尽风险——此时除 max_size 外，还应同步限制 max_files 或启用基于 LRU/LFU 的智能淘汰
结合缓存淘汰机制形成闭环控制
仅设 max_size 不够，必须配套主动淘汰逻辑，否则缓存会卡在上限不动，新内容无法写入。常见组合方式：
- Nginx 场景：配合 proxy_cache_path 中的 inactive（如 1d）和 use_temp_path=off，确保过期/冷数据被及时清理，避免临时文件绕过限额
- Varnish 场景：使用 malloc,180G 定义存储大小，并启用 -s malloc,180G -p default_ttl=3600 -p expiry_sleep=10，让后台线程周期性回收
- 自研缓存：在写入路径中嵌入实时磁盘用量检查，当使用率 >95% 时自动降级（如跳过缓存写入、返回 503）、并触发紧急清理任务
监控与告警必须绑定真实用量
不能只看 max_size 配置值，而要持续采集实际占用（如 du -sh /path/to/cache 或通过缓存引擎内置指标）。重点监控三项：
- 缓存目录实际磁盘使用率（非文件系统整体）
- 缓存淘汰速率（单位时间淘汰条数）——骤升说明有异常热key或爬虫刷量
- 缓存写入失败次数（如 Nginx 的
proxy_cache_background_update失败日志）
当使用率持续 >90% 或淘汰速率突增 3 倍以上，立即触发企业微信/钉钉告警，并自动执行限速策略（如对高频回源IP限流）。
防御恶意填充攻击的加固要点
攻击者可能构造海量唯一URL（如带随机参数的图片请求）绕过常规缓存键去重，导致磁盘被无效内容快速填满。此时 max_size 是最后防线，但需前置加固：
- 在接入层（如 Nginx）用 map 指令识别并丢弃含可疑参数（如
uuid=、ts=）的请求，不进入缓存流程 - 对静态资源路径强制标准化：统一移除无意义查询参数（
nginx.conf中用 rewrite + add_header X-Cache-Key 控制缓存键生成逻辑） - 开启缓存键长度/复杂度校验，拒绝超长或含非法字符的 key 写入
max_size 不是孤立参数，它是磁盘防护体系中的“硬闸门”，只有与淘汰策略、监控反馈、入口过滤联动，才能真正筑牢防线。
