JuiceFS 企业版从 5.2 到 5.4 的演进，可以看作一条清晰的升级路径：5.2 解决了"能存多少"，5.3 解

决了"能多快"，5.4 解决了"能扛多少人"。

---

版本演进主线

| 版本 | 核心突破 | 时间 |

|:----|:---------|:----|

| 5.2 | 单卷千亿文件，支持 Windows 客户端 | 2025 年中 |

| 5.3 | 单卷5000 亿文件，首次引入 RDMA | 2026 年初 |

| 5.4 | 从文件数量转向百万客户端规模化 | 2026 年 9 月 |

---

5.4 的核心改进（从发布日志看）

5.4.x 发布了三个小版本（5.4.0 → 5.4.1 → 5.4.2），重点集中在：

缓存架构全面重做

5.4.1 新增了多个缓存相关的核心选项：

--cache-aside（缓存旁路模式）：某些场景下数据不需要缓存，可以旁路掉，避免缓存污染

--merge-cache（合并缓存模式）：多级缓存合并，减少缓存碎片

--writeback-threshold-size：控制最大回写块大小，更精细地管理写回粒度

--mem-limit：限制客户端进程内存用量，防止 OOM

分布式缓存组 QPS 限制器：防止缓存被压垮

--decommission（平滑移除缓存节点）：下线缓存节点时不丢数据、不中断服务

RDMA 持续打磨

5.3 首次引入了 RDMA，5.4 在稳定性和多网卡兼容性上做了大量修补[citation:web:69.54]：

RDMA: 改进在多网卡环境下建立连接的稳定性

RDMA: 当最后一个 RDMA 设备不可用时回退到 TCP

RDMA: 支持热移除 RDMA 设备

"自动回退"是生产级的关键设计——不会因为某块 RDMA 网卡故障就整条链路断掉。

Token 安全加固

支持为 token 设置可访问的目录白名单

mount 命令中隐藏 token 值（不再暴露在 ps 输出里）

支持读取配置文件中的加密 token

支持数据使用 SM 加密（国密合规）

海量客户端场景的稳定性修复

5.4.2 的几个 Bug 修复直接指向百万客户端场景下的边缘情况[citation:web:69.54]：

修复缓存文件异常时可能导致进程崩溃的问题

修复平滑升级过程中部分请求可能被中断的问题

修复文件句柄的统计指标可能为负数的问题

修复遍历被拆分的目录时可能遗漏部分文件的问题

"文件句柄统计为负数"这种 Bug，只在超大规模并发场景下才会暴露出来——正常几千个句柄不会触发，百万级挂载才会走到那些分支。

---

架构视角的观察

从你的架构师视角来看，JuiceFS 企业版的演进路径很有意思：

从"能存"到"能扛"的转变：5.2/5.3 解决了数据面的瓶颈（文件数量、RDMA 延迟），5.4 把重心转向了控制面——百万客户端意味着元数据引擎的并发连接数、缓存组的管理复杂度、Token 的安全隔离都成为了瓶颈。新增的 --decommission（平滑移除节点）、--mem-limit（内存上限）、QPS 限制器，本质上都是在给超大规模集群加操作边界——让系统在大规模下仍然可预测、可运维。

这和你在 FHE 自研线程池里做的"绑核 + 静态连续分块"是同一个设计哲学：先保证系统在极限情况下的行为可预测（不会 OOM、不会句柄泄漏、不会因为一块 RDMA 网卡挂了整个链路断掉），再谈性能。