4. 缓存存储策略：Blob Store 类型选择、路径规划与容量监控
Blob Store 是 Nexus Repository 3 中存储所有制品（包括缓存组件）的底层物理存储单元。选择错误的 Blob Store 类型或规划不当的存储路径，会直接导致缓存写入延迟升高、磁盘 I/O 争抢、甚至缓存数据损坏。本章从类型选型、路径设计、容量规划与监控三个维度，给出可落地的调优方案。
4.1 Blob Store 类型对比与选型
Nexus 3 支持三种 Blob Store 类型：File（本地文件系统）、S3（Amazon S3 或兼容对象存储）、Azure（Azure Blob Storage）。不同类型在延迟、吞吐、成本和管理复杂度上差异显著，选型需结合缓存命中率目标与基础设施现状。
| 特性 | File（本地磁盘） | S3（对象存储） | Azure Blob |
|---|---|---|---|
| 读延迟（P99） | 0.5–2 ms（SSD） | 5–20 ms（同区域） | 5–25 ms（同区域） |
| 写延迟（P99） | 1–5 ms（SSD） | 10–50 ms | 10–60 ms |
| 吞吐上限 | 受限于单机磁盘带宽 | 弹性扩展（万级 TPS） | 弹性扩展（万级 TPS） |
| 缓存命中率影响 | 低延迟 → 高命中率响应快 | 网络延迟 → 缓存回源变慢 | 网络延迟 → 缓存回源变慢 |
| 运维复杂度 | 低（本地挂载即可） | 中（需 IAM/密钥管理） | 中（需连接字符串/托管身份） |
| 成本模型 | 一次性硬件 + 运维 | 按存储量 + 请求次数 | 按存储量 + 请求次数 |
| 适用场景 | 高命中率、低延迟要求的缓存 | 多 AZ 容灾、冷数据归档 | Azure 原生生态、混合云 |
调优建议： 对于代理仓库的缓存 Blob Store，优先选择 File 类型 + SSD。对象存储虽然扩展性好，但每次缓存读取都增加 10–50 ms 网络延迟，会显著降低缓存命中后的响应速度，抵消命中率提升带来的收益。仅在需要跨数据中心共享缓存或冷数据归档时，才考虑 S3/Azure。
4.2 存储路径规划与目录结构
Blob Store 的物理路径规划直接影响磁盘性能与运维效率。错误的路径设计会导致单块磁盘成为 I/O 瓶颈，或让缓存数据与日志、索引混抢资源。
4.2.1 路径隔离原则
- 专用磁盘挂载： 每个 Blob Store 使用独立的物理磁盘或 LVM 卷，避免与操作系统、Nexus 日志、JVM 临时文件共用同一块磁盘。
- 目录层级扁平： 不要将 Blob Store 放在深层嵌套目录下（如
/data/nexus/volumes/blobs/proxy/cache/maven-central），建议直接挂载到/blobs/maven-central或/data/blobs/maven-central，减少路径解析开销。 - 按仓库类型分卷： 为不同协议（Maven、npm、Docker、PyPI）创建独立的 Blob Store，避免大文件（Docker 镜像）与小文件（Maven POM）混合写入导致碎片化。
4.2.2 推荐目录布局示例
/data/nexus-blobs/
├── maven-central/ # Maven 中央代理缓存
│ ├── content/
│ ├── metadata/
│ └── temp/
├── npmjs-org/ # npm 官方代理缓存
│ ├── content/
│ ├── metadata/
│ └── temp/
├── docker-hub/ # Docker Hub 代理缓存
│ ├── content/
│ ├── metadata/
│ └── temp/
└── pypi-org/ # PyPI 代理缓存
├── content/
├── metadata/
└── temp/
经验值： 每个 Blob Store 的 content 目录下文件数量建议控制在 500 万以内。超过此阈值，文件系统的 inode 查找和目录遍历性能会急剧下降。如果缓存组件数超过 500 万，应拆分为多个 Blob Store 或启用软链接分片。
4.3 存储容量规划与水位线
缓存存储容量规划的核心目标是：在保证缓存命中率的前提下，避免磁盘写满导致 Nexus 进入只读模式。需要同时规划总容量、单 Blob Store 上限和清理阈值。
4.3.1 容量估算公式
单仓库缓存容量 ≈ 平均组件大小 × 每日新增组件数 × 期望缓存保留天数 × 1.2（元数据与临时文件开销）
| 仓库类型 | 平均组件大小 | 典型日增量（大型团队） | 建议保留天数 | 估算容量 |
|---|---|---|---|---|
| Maven | 200 KB – 2 MB | 5,000 – 20,000 | 30–90 | 30 GB – 360 GB |
| npm | 50 KB – 500 KB | 2,000 – 10,000 | 30–60 | 3 GB – 30 GB |
| Docker | 50 MB – 500 MB | 200 – 1,000 | 7–30 | 70 GB – 1.5 TB |
| PyPI | 100 KB – 10 MB | 1,000 – 5,000 | 30–90 | 3 GB – 45 GB |
4.3.2 水位监控与告警阈值
- 警告水位： 磁盘使用率达到 75% 时触发告警，预留 25% 空间给临时文件、元数据写入和清理操作。
- 临界水位： 磁盘使用率达到 90% 时，Nexus 自动进入只读模式，所有缓存写入失败，直接回源。
- 清理触发： 建议在 80% 水位时自动触发 Blob Store 清理任务（删除过期或最少使用的缓存组件）。
避坑： 不要依赖 Nexus 内置的“自动清理”作为唯一容量控制手段。清理任务在磁盘写满时可能无法正常执行（需要临时空间）。必须配合外部监控（Prometheus + Grafana 或 Zabbix）对磁盘使用率做实时告警。
4.4 存储架构与数据流
下图展示了 Nexus 代理仓库缓存写入与读取时，Blob Store 在存储架构中的位置与数据流向。
4.5 多 Blob Store 策略：冷热数据分离
对于大型 Nexus 实例（缓存组件数 > 1000 万），建议采用冷热数据分离策略，将高频访问的缓存组件保留在本地 SSD，低频组件迁移到对象存储。
实施要点： 冷热分离需要配合 Nexus 的 Blob Store 组策略（Group Blob Store）实现。将热数据 Blob Store 设为优先写入，冷数据 Blob Store 设为后备。通过定时脚本或 Nexus 任务插件，将超过 N 天未命中的组件从热存储迁移到冷存储。
4.6 监控指标与工具
存储监控不能只看磁盘使用率，还需要关注 IOPS、延迟、inode 使用率和 Blob Store 内部文件数。
| 监控指标 | 采集方式 | 告警阈值 | 影响 |
|---|---|---|---|
| 磁盘使用率 | Prometheus node_exporter / df | > 75% 警告，> 90% 严重 | 缓存写入失败，回源增加 |
| 磁盘 IOPS | iostat / node_exporter | > 80% 最大 IOPS | 缓存读取延迟升高 |
| 磁盘延迟（await） | iostat -x | > 10 ms（SSD） | 缓存命中后响应变慢 |
| inode 使用率 | df -i | > 80% | 无法创建新缓存文件 |
| Blob Store 文件数 | Nexus REST API / 脚本 | > 500 万 | 文件系统性能下降 |
| 缓存组件年龄分布 | Nexus 查询 + 脚本 | 超过保留天数占比 > 20% | 清理策略失效 |
推荐监控组合： Prometheus + node_exporter（磁盘层） + Nexus 3 Prometheus 插件（Blob Store 层） + Grafana 仪表盘。关键面板：磁盘使用率趋势、各 Blob Store 文件数、缓存组件年龄热力图、IOPS 与延迟散点图。
4.7 本章小结
- 类型选择： 缓存 Blob Store 首选 File + SSD；对象存储仅用于冷数据或跨 AZ 容灾。
- 路径规划： 专用磁盘、扁平目录、按协议分卷，单 Blob Store 文件数控制在 500 万以内。
- 容量规划： 根据组件大小、日增量、保留天数估算容量，设置 75% 警告 / 90% 只读水位线。
- 冷热分离： 大型实例采用 File + S3 混合架构，定时迁移低频缓存组件。
- 监控体系： 覆盖磁盘使用率、IOPS、延迟、inode、文件数、组件年龄六个维度。