第 20 章 Red Stuff、纠删码与可用性
Walrus 的数据不是简单复制 N 份。它使用纠删码把原始 Blob 编码为多个片段，只要取回足够多的片段就能重构数据。Red Stuff 是 Walrus 论文和实现中围绕可用性证明、编码片段和存储节点确认的一组协议设计。
本章不推导公式，只讲开发者要用到的结论。
纠删码解决什么问题
复制的思路是“多存几份完整文件”。纠删码的思路是“把文件变成更多片段，丢一部分也能恢复”。它的优势：
- 在同等可靠性下节省存储成本。
- 单个节点离线不一定影响读取。
- 可以让可用性证明围绕片段而不是整文件展开。
代价是：
- 写入前需要编码，读取时可能需要重构。
- 小文件会有固定开销，适合用 Quilt 或批处理降低成本。
- 读取延迟取决于足够多片段的响应速度，而不是最快一台节点。
开发者看到的现象
纠删码会带来几个工程现象：
- 同一个 Blob 的读取延迟可能波动，因为 aggregator 要联系多个节点。
- 某些存储节点失败时，读取仍可能成功。
- 如果不足够多片段可用，读取会失败，而不是返回“部分文件”。
- 大文件比小文件更能摊薄元数据和编码开销。
所以不要用一次读取失败判断 Blob 已经丢失。先换 aggregator、重试、查链上状态，再判断是否过期或不可用。
小文件策略
大量小 JSON、图片缩略图、配置片段直接逐个上传，会把固定开销放大。推荐：
- 使用 Quilt 把多个小文件打包。
- 在业务索引里保存 Quilt 内部路径或 key。
- 对热点小文件做应用级缓存。
- 把频繁变化的小状态留在数据库或 Sui 对象里，不要每次都写 Walrus。
Walrus 适合保存 Blob，不适合替代键值数据库。
可用性和持久性
可用性是“现在能不能读到足够片段”，持久性是“未来一段时间内数据不会丢”。它们有关但不是同一个指标。
应用要分别监控：
- 当前读取成功率。
- 写入成功率。
- Blob 到期时间。
- 多 aggregator 读取一致性。
- 存储节点或服务版本是否落后。
如果只监控 HTTP 200，会漏掉续期失败、慢读、数据校验失败和网络分区。
和业务哈希配合
Walrus 的 blob_id 是协议层标识。业务系统仍建议保存自己的内容摘要：
sha256(original_bytes) -> business_hash
用途：
- 防止上传前后拿错文件。
- 支持业务去重。
- 支持审计和用户可见校验。
- 支持加密场景下区分明文哈希和密文哈希。
敏感数据要注意：明文哈希可能泄露已知文件的存在性。隐私场景更适合保存密文哈希或带盐摘要。
调优方向
如果你的读取慢，排查顺序通常是：
- aggregator 是否过载或离用户太远。
- Blob 是否为冷数据，缓存命中率低。
- 存储节点响应是否长尾严重。
- 客户端是否串行读取大量小 Blob。
- 应用是否没有使用 Range、批量索引或 CDN。
不要先怀疑纠删码本身。多数延迟问题来自接入层、网络和请求形态。