随着面向大规模并发读取与数据分发的业务需求增加，如影视渲染等场景，传统存储方案（如 NAS）在并发客户端数量增加时，往往需要投入更多缓存资源；为了提升响应时效，通常还需提前进行数据预热，不仅带来额外的时间开销，也进一步加重了资源负担。
JuiceFS 作为一种基于对象存储的分布式文件系统，通过其高性能架构，利用分布式缓存聚合吞吐量并降低延迟，能够在大规模客户端并发读取时提供高效支持。本文分享的是我们近期在实际测试中的一个案例，展示如何利用 4,000 台业务节点成功聚合了 1.45TB/s 的带宽，并在此过程中通过引入二级缓存池，保障了系统的稳定性。
通过这篇文章，我们希望为高并发、大吞吐需求场景中的存储瓶颈提供一个切实可行的解决方案，并借此抛砖引玉，欢迎大家共同探索存储优化的思路与方法。
01 传统 NAS：节点越多，存储越慢
该客户为影视渲染农场用户，日常作业中会同时启动数千台 Windows 节点进行渲染。
- 业务特点：每台节点在渲染时需同时读取一批文件（大部分为重复素材）到本地。
- 原有痛点：原公有云 NAS 存储（SMB 挂载）在节点数增多时，不得不不断增加后端 SMB 服务节点来应对激增的流量和 IOPS，导致管理复杂度和成本直线上升。当并发节点超过 1,000 台时，存储系统往往不堪重负。
- 核心需求：迫切需要一种在存储底座之外，能够分担业务吞吐压力的能力。
在 SMB 服务模式下，每个客户端都需要从 SMB 存储读取全量数据。导致服务端流量长期高位，管理员需要持续监控 SMB 服务的健康状况，一旦接近最大负荷，就需要及时进行扩容，提供与集群规模匹配的存储能力，运维压力显著增加。
02 闲置资源利用：用大量业务节点做分布式缓存
JuiceFS 在社区版 1.3 及企业版 5.2 之后发布了全新的 Windows 客户端，支持通过.exe进程将文件系统挂载为本地盘，使用方式与 Linux 类似。
但在海量客户端场景下，如果仅将业务切换为标准的「JuiceFS 挂载点 —— 分布式缓存 —— 对象存储」链路，流量会集中打到独立缓存层，可能成为新的性能瓶颈。与其不断扩容专用的缓存节点，不如转换思路：利用海量业务节点自身的闲置带宽和磁盘，将它们池化为一个巨大的分布式缓存池。
- JuiceFS 分布式缓存模式（P2P 模式）：同一份文件只需在集群内读取一次，后续其他节点直接从 P2P 缓存池的邻近节点获取。
- 对象存储侧：回源流量极低，文件首次冷读后，后续流量几乎全由缓存池承担。
- 资源要求：无需专用缓存硬件，仅需每个业务节点贡献部分磁盘和带宽。
在这个方案中，我们没有配置任何一台独立缓存节点。所有的业务节点既是消费者，也是提供者（P2P 模式）。
03 实测案例：4,000 台业务节点聚合到 1.45TB/s 的巨大吞吐
测试任务：每台 Windows 机器在无预热（冷读）的情况下，读取 16 个 2GB 的大文件。 统计所有节点读完的总耗时，并观察各节点的耗时方差，以及是否存在长尾效应。
配置策略：将 4,000 个节点拆分为多个子组（每组 500 个节点）。16 个 2GB 的数据块会散列分布在组内节点中，避免所有节点同时回源对象存储，造成拥塞。
那么现在 JuiceFS 客户端的冷读流程就变为：
- Windows 客户端读取 16 个 2GB 的文件，通过一致性哈希拓扑定位这些数据块在 500 个缓存组内的负责节点，向其发起请求。
- 缓存节点收到了数据块请求后，发现本地未命中缓存（冷读），则回源对象存储拉取数据块，拉取完成后将数据返回给客户端，并且写入本地缓存，供后续请求复用。
- 当客户端从所有缓存服务节点获取完整数据块后，测试结束，统计所有客户端读完的耗时分布（最大值、最小值），用于评估方差与长尾情况。
下面是不同客户端节点数量读取这批 16*2GB 大文件的时间结果：
| 客户端台数 | 聚合吞吐最高 | 总耗时（范围/平均） |
|---|---|---|
| 2,000 台 | 729GB/s | 92s~136s 平均 107s |
| 2,500 台 | 921GB/s | 87s~109s 平均 98s |
| 3,000 台 | 1.11TB/s | 93s~121s 平均 106s |
| 3,500 台 | 1.34TB/s | 89~112s 平均 100s |
| 4,000 台 | 1.45TB/s | 92s~115s 平均 101s |
不同数量客户端，JuiceFS 聚合吞吐表现
整体结果各方面都符合预期：
- 稳定性：无论是 2,000 台还是 4,000 台，读完数据的总耗时都稳定在 100 秒左右。
- 扩展性：4,000 台节点成功聚合出 1.45TB/s 的超大带宽，理论上，在元数据能够承载的前提下，该架构可实现持续的水平扩展，能够支持达到万台级别的缓存节点规模。
业务节点的挂载参数参考：
juicefs.exemountjuice-fs X: --cache-group=primary --buffer-size=4096--enable-kernel-cache --as-root --subgroups=8由此，我们未使用一台独立的缓存服务节点，仅靠用户的业务节点就聚合了 1.45TB/s 的读取能力。过客通户端节点组成的分布式缓存层，我们以零成本将绝大多数流量从对象存储中分流，减轻了底层存储的负担。
实际业务中，未必能达到如此高的吞吐能力，因为缓存效益通常与数据重复度相关。在实际场景中，每个节点读取的文件并不完全相同。尽管如此，这一方案仍然是有效的存储扩展方法，即使只有部分提升，也能带来非常可观的收益，且几乎不需要额外的成本投入。
04 稳定性增强：两级分布式缓存
缓存效果虽然炸裂，但客户对系统的稳定性提出了担忧。例如，在某些场景下，业务节点在完成任务后会立即销毁，而这些业务节点同时也是缓存节点。当大量业务节点突然下线时，原本存储在这些节点上的缓存也随之丢失，导致大量流量回源至对象存储，进而使对象存储成为瓶颈，影响整体稳定性。为了解决因业务节点波动引发的缓存性能问题，我们提出了两级分布式缓存方案，架构图如下：
第二层缓存池（L2）位于第一层（L1）缓存池和对象存储之间。当 L1 未命中时，数据首先会从 L2 获取；如果 L2 缓存也未命中，则回源到对象存储。这样可以有效抵消 L1 缓存节点波动带来的影响。加入 L2 缓存池后，读取流程发生了以下变化：
- 在 Windows 客户端读取 16 个 2GB 的文件，通过一致性哈希拓扑确定数据块所在 L1 缓存组中的特定节点；并同时向 L2 缓存组请求数据。
- 由于是冷读，L2 缓存组中没有数据，L2 缓存节点会向对象存储发起请求并填充 L2 缓存池。
- 数据块从 L2 缓存池返回至 L1 缓存池并进行填充，然后由 L1 缓存池内的节点自行进行点对点（P2P）分发。
- 此时，大部分流量集中在 L1 缓存池，L2 只处理极少数回源对象存储的流量，因此即使 L2 只有少数几个节点，也不会成为性能瓶颈。L2 缓存池的作用是就近替代对象存储，降低延迟。
即使大量 L1 业务节点下线，缓存拓扑发生变化并需要重新下载数据块，数据仍可从 L2 缓存池就近获取。只要合理控制下线比例，业务几乎不受影响。
L2 缓存组挂载参数：
juicefsmountjuice-fs /jfs-cache --cache-group=secondary --cache-size=-1 --cache-dir=/data* --free-space-ratio=0.01--buffer-size=10240--max-downloads=400L1（业务节点）挂载参数：
juicefs.exemountjuice-fs X: --cache-group=primary --second-group=secondary --buffer-size=4096--enable-kernel-cache --as-root --subgroups=8此外，两级分布式缓存还非常适用于需要重复利用已有缓存池的场景。例如，我们有一批位于北京的缓存池业务，总容量为 2PiB，缓存池名为 cache-group-bj。突然，上海的业务也需要使用相同的数据，而这些数据与北京的数据几乎完全相同。如果不希望重新从北京的对象存储中预热这 2PiB 的数据，我们可以在上海的缓存组中配置--second-group=cache-group-bj。这样，当上海的业务请求数据时，将优先通过专线从北京的缓存池读取数据，速度非常快且延迟稳定（在 2ms 以内），免去了重复预热数据的复杂过程，能够直接启动业务，极大地方便了操作。
05 小结
通过本次 4,000 节点的极限压测，我们成功将计算集群的大规模闲置资源转化为高达 1.45TB/s 的存储池；而二级缓存的引入，有效解决了“最后一公里”的稳定性顾虑。通过使用 JuiceFS 这套存储软件架构，可充分挖掘客户端集群的潜能，在不增加额外硬件成本的情况下，实现了性能的显著提升。
本方案适用场景：
- 高并发重复读取场景：如模型训推数据调用、容器镜像分发、影视渲染等，节点越多，P2P 缓存收益越大；
- 弹性计算场景：业务节点经常大规模扩缩容（如 Spot Instances），利用二级缓存架构可确保数据访问的连续性与稳定性；
- 混合云/多云架构：利用二级缓存机制可以复用异地缓存池资源，最大程度减少重复预热带来的对象存储调用和传输成本。
我们希望本文中的一些实践经验，能为正在面临类似问题的开发者提供参考，如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。
