本文使用通用仓库名、域名和容量。删除 hosted 制品可能不可恢复，所有命令应先在测试环境验证并完成备份。
Nexus 页面提示“实例正在接近使用限制”，这不是磁盘空间告警，也不表示 Kubernetes 不允许运行社区版。
截至本文核对时，Sonatype 官方 Usage Center 说明，Community Edition 的限制为：总组件数 40,000，或每日请求数 100,000；超过任一限制后将无法新增组件，回落到限制以内才会恢复。指标更新最多可能需要约一小时。Usage Center
这些规则取决于产品版本和许可策略，执行前应再次查阅官方页面。
先分清四个容易混淆的概念
| 概念 | 含义 | 是否等于 CE 用量 |
|---|---|---|
| Component | Nexus 管理的逻辑组件/版本 | 是，影响组件数 |
| Asset | POM、JAR、校验文件等具体文件 | 不等同于组件数 |
| Blob Store 空间 | 文件实际占用磁盘 | 不等同于组件数 |
| Request | 客户端下载、查询、上传请求 | 影响每日请求量 |
maven-public 通常只是一个 Maven Group 仓库名，不代表“Public 版本”或另一种 Nexus 许可证。
Hosted、Proxy、Group 的清理风险不同
hosted
保存企业自己发布的 Release 和 Snapshot。删除这些制品可能导致构建产物永久丢失，必须先确认：
- 是否仍被生产环境、历史分支或回滚使用。
- 源码能否重建出完全相同的二进制。
- 是否满足审计和保留期。
- 是否已有离线备份。
proxy
保存上游仓库缓存。上游仍存在且网络可靠时，缓存通常可以重新下载，因此更适合作为优先治理对象。
但上游组件可能已被删除、变更，或因网络不可达而无法重新获取。不能把所有 proxy cache 都视为无价值。
group
Group 本身聚合其他仓库，一般不是直接存储制品的清理对象。应清理的是它包含的 hosted/proxy 成员。
第 1 步：备份数据库与 Blob Store
Nexus 使用 PostgreSQL 时，备份必须覆盖：
PostgreSQL 数据库
全部 Blob Store
/nexus-data 中的配置和密钥
Kubernetes Secret 与清单数据库和 Blob 的时间点要协调。只备份数据库，恢复后会出现元数据指向不存在文件的情况；只备份 Blob，也无法重建完整仓库状态。
pg_dump -Fc -h <postgres-host> -U <backup-user> <nexus-database> \
-f backup/nexus-before-cleanup.dump
sha256sum backup/nexus-before-cleanup.dump \
> backup/nexus-before-cleanup.dump.sha256Blob Store 按底层存储能力创建只读快照或一致性备份。不要在 Nexus 正在大量写入时直接打包目录。
第 2 步：记录清理前基线
在 Usage Center 截图或导出：
- Total Components。
- Daily Requests。
- 指标更新时间。
记录仓库和 Blob：
curl --fail --silent --show-error \
--netrc-file <secure-netrc> \
https://repo.example.com/nexus/service/rest/v1/repositories \
> reports/repositories-before.json
curl --fail --silent --show-error \
--netrc-file <secure-netrc> \
https://repo.example.com/nexus/service/rest/v1/blobstores \
> reports/blobstores-before.json不要把带凭据的命令、.netrc 或 API 响应中的内部信息提交到公开仓库。
第 3 步：按仓库类型盘点
创建表格：
repository,format,type,owner,retention_days,upstream_recoverable,cleanup_policy
maven-releases,maven2,hosted,release-team,365,false,manual-review
maven-snapshots,maven2,hosted,dev-team,30,true,snapshot-retention
maven-central,maven2,proxy,platform-team,60,true,proxy-cache优先级通常是：
失效 proxy cache
→ 过期 Snapshot
→ 无引用的临时 hosted 制品
→ Release 人工审计第 4 步：分页导出组件，避免只看 UI
Nexus Components API 使用 continuation token 分页。单页结果不能代表仓库总量。
请求结构：
curl --fail --silent --show-error \
--netrc-file <secure-netrc> \
'https://repo.example.com/nexus/service/rest/v1/components?repository=<repository>'自动化脚本应：
- 保存
items。 - 读取
continuationToken。 - continuationToken 非空时继续请求。
- 只输出脱敏后的 group/name/version/lastModified。
- 生成候选，不直接 DELETE。
第 5 步：先找消费者，再决定删除
搜索：
- Maven POM、Gradle、npm lockfile。
- Jenkinsfile 和流水线参数。
- Kubernetes 镜像与启动脚本。
- Git tag、Release 和维护分支。
- 生产回滚清单。
某个 Release 制品没有被当前主干引用，不代表历史版本不再需要它。
候选清单至少需要制品负责人和运维双方确认。
第 6 步：为 Proxy 配置 Cleanup Policy
在 Nexus 管理界面创建 Cleanup Policy，根据目标版本支持的条件设置：
- Last downloaded before。
- Last blob updated before。
- Release type 或格式相关条件。
- 名称正则，仅匹配明确指定的命名空间。
先关联一个低风险 proxy 仓库，等待任务执行并抽样验证；不要一开始就关联所有仓库。
第 7 步：治理 Snapshot
Snapshot 常见规则：
保留最近 N 个版本
保留最近 N 天
保留仍被活跃分支引用的版本
Release 不套用 Snapshot 规则删除前用一个隔离 Maven 项目验证最新和历史 Snapshot 的下载路径。清理后验证仍在保留范围内的版本。
第 8 步：按正确顺序运行任务
不同 Nexus 版本的任务名称可能变化，推荐的执行顺序是：
执行 Cleanup Policy
→ 等待逻辑删除完成
→ 删除不再引用的 Blob
→ Compact Blob Store
→ 等待数据库与 Usage Center 指标更新Compact Blob Store 主要回收磁盘空间，不等于立即降低组件数。不要因为磁盘空间没有立刻变小就再次大批量删除。
执行任务时记录：
- Task ID、开始和结束时间。
- 删除候选数量。
- Task 日志和错误。
- Blob 空间变化。
- Usage Center 更新时间。
第 9 步：验证代理缓存能否重新拉取
清理 proxy cache 后，使用一个空的 Maven 本地仓库，重新下载允许删除的组件：
mvn -Dmaven.repo.local=<temporary-empty-directory> \
dependency:get \
-Dartifact=<group>:<artifact>:<version>同时观察 Nexus request log 和 proxy remote 状态。上游不可用时，应停止扩大清理。
第 10 步：验证 Hosted 仓库
至少完成：
- 下载保留的历史 Release。
- 下载最新 Snapshot。
- 上传新的测试 Snapshot。
- 使用 CI 账号发布与读取。
- 使用匿名/普通账号验证权限没有变化。
如果已超过 CE 限制，新增组件可能仍被阻止，需要等待指标回落后才能确认；根据官方说明，Usage Center 指标可能最多延迟约一小时。
每日请求数超限怎么办
清理组件不能直接降低请求量。应分析：
- CI 是否每次都强制更新全部依赖。
- 是否有错误重试或健康检查高频访问仓库。
- 开发机构建是否绕过本地缓存。
- 同一个组件是否被大量重复下载。
- 代理、镜像和构建缓存策略是否合理。
不要为了减少请求而给 Release 返回过长且不可撤销的缓存头。
为什么不应该修改源码绕过限制
- 限制可能同时存在于 UI、服务端写入路径和许可状态。
- 修改源码会失去官方升级和安全补丁路径。
- 数据库结构和任务行为无法获得支持。
- 下一次升级可能直接破坏自定义修改。
- 许可条款不是一个前端数字可以改变的。
正确的选择是降低真实用量、调整架构，或购买符合规模的版本。
什么时候考虑 Pro
- 正常业务组件数量长期超过 CE 限制。
- 每日请求量来自合理 CI/CD，而不是错误流量。
- 制品保留期受审计要求约束，不能继续删除。
- 需要官方 HA、支持或企业能力。
- 清理成本已经高于许可证和运维带来的收益。
完成定义
- 数据库和 Blob Store 完成一致性备份与恢复验证。
- 每个仓库有所有者、类型和保留策略。
- Proxy、Snapshot、Release 使用不同清理规则。
- 删除候选均有引用扫描和人工审批。
- Cleanup 与 Blob Compact 任务顺序正确且日志完整。
- Maven 下载、发布和 CI 构建通过。
- Usage Center 在指标刷新后回到安全范围。
- 清理规则进入定期审计，而不是接近限制时临时删除。
Nexus 容量治理的目标不是让页面数字暂时变小，而是让制品生命周期、缓存、审计和恢复能力长期处于可控状态。
DISCUSSION
讨论与反馈