存文件时副本放对地方，后面纠删码能快很多

2026-05-26

865

大型集群文件系统常见的一种做法：新写入的数据先用三副本顶住读性能和故障恢复，等数据“变旧”以后，再在后台转成更省空间的纠删码。这个流程看起来顺理成章，但这篇论文指出：副本先被随机地扔到各个节点和机架里，却没有为后面的编码做任何准备。

一旦开始把这些副本改写成纠删码，随机放置的副本就会带来两个麻烦。第一个麻烦是慢：编码一个条带时，需要把同一组里的多个数据块拉到同一个节点上，如果它们分散在不同机架，就要走代价更高的跨机架带宽。第二个麻烦是不稳：编码完成后，为了满足机架级容错要求，系统还可能得再搬一次块；搬迁没做完之前，数据处在一个不那么安全的窗口里。论文要纠正的是：如果系统迟早要做纠删码，那么“复制阶段怎么放副本”就不该和“编码阶段怎么组条带”完全脱节。

作者提出的方法叫“编码感知复制”（encoding-aware replication，EAR）。核心是：对未来会一起编码的一组数据块，EAR 会想办法让每个块至少有一个副本落在同一个“核心机架”里，这样真正开始编码时，负责编码的节点可以在本机架把这一组数据凑齐，尽量不去跨机架取块。与此同时，剩余副本不是随便堆过去，而是按约束分配到其他机架里，让编码完成后的数据块和校验块依然满足节点级、机架级容错要求，尽量避免再做一次搬迁。这篇论文没有重新发明纠删码，而是补上“从复制走到纠删码”这段中间地带。

图 2回答的问题是：随机复制为什么会把编码阶段拖慢，还顺手埋下可用性隐患。值得注意的是图 2(a) 里有一个数据块必须从别的机架拉过来，而图 2(b) 里同一组数据块已经在核心机架里凑齐。作者用这个例子说明，EAR 的价值不是多做了一步“优化”，而是把本来发生在编码之后的跨机架代价，提前在副本布局阶段处理掉了。

图 8 (b)展示了收益：当跨机架网络越紧张时，提前按编码需求放副本值不值？值得注意的是 RR 和 EAR 两组柱子的间距，以及横轴上 UDP 发送速率不断升高时，这个间距怎么被拉大。在固定使用 (10, 8) 纠删码的条件下，随着额外网络流量从 0 提高到 800 Mb/s，EAR 相对随机复制的编码吞吐提升从 57.5% 拉大到 119.7%。说明EAR 的收益不是抽象的“更优”，是非常贴近集群文件系统的真实瓶颈：跨机架带宽越稀缺，随机复制留下的后遗症就越重， EAR 正好对着这个瓶颈下手。

图 9 进一步说明EAR不是“后台编码自己快一点”这么简单。当系统一边接收写请求、一边在后台做编码时，前台业务会不会被拖慢。可以看 30 秒以后编码任务启动后，两条响应时间曲线的分离程度，以及图中横线标出的整体编码时长。结果是，EAR 把写请求平均响应时间压低了 12.4%，把整个编码过程的总耗时缩短了 31.6%。把副本先放对地方，不只帮存储系统省出一块后台时间，也在高负载时顺手减轻了前台写入被跨机架流量挤占的压力。

论文还有一个很重要的点：EAR 的改进不是靠“副本堆在一个地方”换来的。图 14 可知副本会不会因此失去均衡分布，需注意不同机架上的副本占比是否被少数机架明显吃掉。结果是RR 和 EAR 在各机架上的副本占比都落在 4.1% 到 5.9% 之间。图 15 可知读请求会不会因此更容易形成热点，代表最热机架压力 hotness index H的两种方案几乎重合。这一点很关键：如果一种“更快”的方案只是把热点藏起来，很难在真实系统里站住脚。

这篇论文讨论的是像 HDFS 这样先复制、后异步做纠删码的集群文件系统，且跨机架带宽本来就是稀缺资源。它的收益还会随着参数变化而变化。图 13(c) 表明：链路越紧EAR 越占便宜， 0.2 Gb/s 链路条件下的编码吞吐提升可以到 165.2%；图 13(e) 可知，性能提升和容错目标之间存在权衡，如果少容忍一些机架故障，EAR 的收益会更大。