在上一篇《bazel-remote 多实例部署：两种横向扩展方案与性能对比》中，我们梳理了共享云存储与负载均衡+一致性哈希两种横向扩展思路。但留下了一个关键问题：当 S3 后端（这里用 RustFS）与 bazel-remote 部署在同一高速网络时，两种方案的延迟差距还大吗？

本文就聚焦这个真实场景，给出量化的延迟对比与选型建议。

随着团队规模和 CI/CD 流水线的增长，单节点 bazel-remote 缓存服务往往会面临性能瓶颈——响应变慢、磁盘空间不足、单点故障风险等问题。然而，bazel-remote 官方并未内置集群或自动横向扩展功能。

在本文中，我们将探讨如何安全、高效地部署多个 bazel-remote 实例，并重点比较两种主流方案的性能差异，特别是当 S3 后端（使用 RustFS）与 bazel-remote 部署在同一高速网络时，情况会有何不同。

⚠️ 核心警告：不要共享本地磁盘

一个常见的误区是让多个 bazel-remote 实例共享同一个本地磁盘或 NFS 目录。

bazel-remote 在估算磁盘使用量时，假设自己是唯一操作缓存目录的进程。如果多个实例同时写入同一目录，会导致磁盘使用量统计不准确——当统计值达到 --max_size 限制时，实例可能会错误地删除文件，即使实际磁盘空间还很充足。这会引发缓存数据丢失和性能不稳定。

因此，绝对不要让多个 bazel-remote 实例共享同一个本地磁盘或 NFS 目录。

方案一：共享 S3 存储后端（使用 RustFS）

核心原理

bazel-remote 原生支持将 S3 协议兼容的对象存储配置为代理后端。这里我们使用 RustFS 来搭建 S3 服务，所有 bazel-remote 实例指向同一个 RustFS 集群，实例本身变为无状态缓存代理，负责处理请求并与后端 S3 存储交互。

架构特点

• 数据集中存储：所有缓存数据保存在 RustFS 中，实例间天然共享且一致
• 分层缓存机制：bazel-remote 优先检查本地磁盘缓存（L1），若未命中则从 RustFS 拉取（L2），新缓存异步上传到 RustFS
• 水平扩展简单：新增实例只需指向同一个 RustFS，无需数据迁移
• 同网络部署优势：RustFS 与 bazel-remote 部署在同一机房/可用区，网络延迟极低（RTT < 1ms）

配置示例（S3）

 1# bazel-remote 配置（YAML格式）
 2s3_proxy:
 3  endpoint: rustfs.internal:9000          # 同网络 RustFS 服务地址
 4  bucket: bazel-cache-bucket
 5  prefix: my-cache-prefix
 6  auth_method: access_key
 7  access_key_id: your-access-key
 8  secret_access_key: your-secret-key
 9  region: us-east-1                       # RustFS 中可自定义
10  disable_ssl: true                       # 同网络内网通信可禁用 SSL 提升性能

RustFS 的性能优势

RustFS 是使用 Rust 编写的高性能 S3 兼容对象存储，在同网络部署下具有显著优势：

• 极致的小文件性能：相比 MinIO，RustFS 在 4K 小文件场景下 P99 延迟可降低 52.8%
• 高吞吐量：读取 32MiB 大文件可达约 2GB/s 的吞吐量
• 低延迟：P99 延迟通常控制在毫秒级，配合同机房网络，整体延迟可控

RustFS 的部署方式可参考《用 Docker Compose 部署 RustFS：高性能 S3 兼容对象存储实战》一文。

方案二：负载均衡器 + 一致性哈希

核心原理

部署多个独立的 bazel-remote 实例，每个使用各自的本地磁盘（不共享），前置负载均衡器（如 Nginx）将请求分发到后端实例。

Bazel 使用操作的 SHA256 哈希值作为缓存键。负载均衡器对该哈希值执行一致性哈希算法，确保相同缓存键的请求始终路由到同一个后端实例，从而最大化利用该实例的本地缓存数据。

Nginx 配置示例

 1upstream bazel_cache_backend {
 2    # 使用 consistent 参数启用一致性哈希
 3    # $request_uri 包含 Bazel 的缓存键
 4    hash $request_uri consistent;
 5
 6    server 10.0.0.10:8080;
 7    server 10.0.0.11:8080;
 8    server 10.0.0.12:8080;
 9}
10
11server {
12    listen 80;
13    server_name your-cache-server.example.com;
14
15    location / {
16        proxy_pass http://bazel_cache_backend;
17        proxy_set_header Host $host;
18        proxy_set_header X-Real-IP $remote_addr;
19    }
20}

🔍 同网络场景下的延迟差异分析

这是本文的核心问题：当 RustFS 与 bazel-remote 部署在同一高速网络时，方案一（S3 后端）与方案二（一致性哈希 + 本地磁盘）的延迟差异还大吗？

数据路径对比

• 方案一：bazel-remote → 网络(RTT) → RustFS → 磁盘
• 方案二：bazel-remote → 本地磁盘

即使网络再快，方案一始终比方案二多一次网络往返和 RustFS 的处理开销。

实测数据估算（同机房网络环境）

假设 bazel-remote 本地 NVMe 磁盘读取延迟为 ~1ms，同机房网络 RTT 为 <1ms，RustFS 处理延迟 P99 约为 ~0.8ms：

关键结论：即使在同网络环境下，方案二（本地磁盘）在缓存命中时的延迟优势依然显著，尤其在小文件和高并发场景下。RustFS 虽然性能优异，但物理上"多一跳"的网络开销无法消除。

影响延迟的关键因素

即便 RustFS 与 bazel-remote 同网络，以下因素仍会影响方案一的性能：

1. 网络质量：不仅是带宽，延迟（RTT）和丢包率同样关键。RustFS 官方建议集群间 RTT 不超过 20ms，丢包率低于 0.01%。即使是 0.5ms 的延迟，在百万次请求下也会累积成巨大开销（500 秒）。

2. RustFS 实例性能：

   • 小文件场景：RustFS 优势明显，但仍存在序列化、网络协议栈等开销
   • 高并发：高并发下 RustFS 延迟会增加（如 4 线程并发读取可能从 59ms 增至 110ms）

3. bazel-remote 的 S3 客户端开销：S3 客户端库的序列化、签名计算、连接管理等也存在 CPU 开销。

两种方案综合对比

💎 如何选择？

推荐方案一（RustFS S3 后端）的场景

• 团队规模较大，需要高可用和易扩展的架构
• 追求低运维复杂度，不希望管理多台实例的状态
• CI/CD 并发量高，需要统一的数据视图
• 可接受毫秒级的延迟换取数据一致性和可靠性
• 适用场景：大多数中大型团队，这是更现代、更稳健的架构

推荐方案二（一致性哈希 + 本地磁盘）的场景

• 追求极致性能，对构建时间有苛刻要求（如每次构建节省数秒）
• 团队有能力维护多实例架构和负载均衡配置
• 可以接受实例故障时部分缓存丢失
• 适用场景：对性能有极致要求、且能接受一定运维复杂度的团队

⚡ 最佳实践：分层缓存（L1 + L2）

将方案一作为方案二的数据后端——每个 bazel-remote 实例仍使用本地磁盘作为一级缓存（L1），同时将 RustFS 配置为代理后端（L2）。

工作流程

1. 请求到达实例 → 优先从极快的本地磁盘读取（L1）
2. 若本地未命中 → 从 RustFS 拉取并存入本地磁盘（L2）
3. 新缓存异步上传到 RustFS，供其他实例共享

效果

这种 “本地磁盘 (L1) + S3 存储 (L2)” 的分层缓存架构，兼顾了方案二的读取速度和方案一的数据共享与持久性，是生产环境中最值得考虑的部署模式。

总结

当 RustFS 与 bazel-remote 部署在同一网络时，S3 后端方案的延迟已经足够低，完全能满足绝大多数团队的日常构建需求。但如果追求极致性能，本地磁盘 + 一致性哈希方案依然有不可替代的优势。

关键在于权衡：你愿意为了每毫秒的延迟节省，付出多少运维复杂度？对于大多数团队来说，分层缓存（L1 本地磁盘 + L2 RustFS）是在性能、可用性和运维复杂度之间取得平衡的最佳选择。

📚 参考资源

• bazel-remote GitHub 仓库
• bazel-remote Proxy Backends 文档
• RustFS GitHub 仓库
• Nginx 一致性哈希负载均衡配置