分布式协调下载20TB级Minecraft世界：NBT区块存储优化与归档管道设计

项目概述与规模

2b2t.place 团队近期完成了 Minecraft 历史上规模最大的世界下载项目，总计约 24TB 的游戏数据。该项目覆盖了 2b2t 服务器（号称 "最古老的无政府服务器"）的多个维度区域：1,024,000×1,024,000 格的主世界区域、512,000×512,000 格的早期主世界快照、256,000×256,000 格的末地区域，以及 100,000×100,000 格的下界区域。整个项目历时超过一年，涉及 28 个机器人账号的分布式协调、数千美元的基础设施投入，以及大量自定义软件的开发。

从技术角度看，这一项目面临的挑战远超普通的世界备份。2b2t 服务器自 2010 年运行至今，地图数据极其庞大且分散，同时服务器的高延迟和队列机制使得数据采集效率极低。团队最终通过自建代理服务器、自定义文件格式和自动化飞行脚本，在 109 天内完成了主世界百万格区域的完整下载。

zvcr 文件格式：NBT 区块存储的重新设计

传统 Minecraft 世界数据使用 MCA（Minecraft Anvil）格式存储，每个区域文件（Region）包含 32×32 个区块（Chunk），采用 NBT（Named Binary Tag）格式序列化。然而，MCA 格式在设计时并未考虑长期归档和版本控制需求，存在冗余度高、压缩率低、缺乏历史快照能力等局限。

zvcr（Zstd-compressed Version Controlled Regions）格式是该项目开发的核心存储方案，在多个维度上实现了优化：

Zstd 压缩替代 GZip：zvcr 采用 Zstd 算法替代 MCA 原生的 GZip 压缩，在压缩级别 22 的设置下，主世界数据可减少 50% 以上存储空间，末地维度由于空气方块占比高，压缩率可达 95%。Zstd 的优势在于解压速度极快，适合需要频繁随机读取的场景。

反向增量版本控制：这是 zvcr 最具创新性的设计。与 Git 等版本控制系统类似，zvcr3 格式在同一文件中存储多个时间点的数据快照。最新快照以完整形式存储，历史版本则通过反向增量（reverse delta）算法计算差异。当需要访问历史状态时，系统从最新快照出发，逆向应用增量即可重建任意时间点的数据。这种设计特别适合 Minecraft 世界的特性 —— 相邻时间点的区块变化通常很小，增量数据体积极小。

调色板压缩（Paletted Storage）：zvcr 沿用了 Minecraft 的调色板机制存储方块状态和生物群系数据，但针对归档场景做了优化。当调色板索引位数超过 8 时，系统切换为直接模式（Direct Mode），使用 16 位固定长度编码，避免调色板本身的开销超过收益。

区块状态元数据：每个区块段（Segment）附加状态标记，区分 "新生成" 与 "已存在" 区块，并记录时间戳。这一设计使得数据分析工具可以快速筛选出特定时间段内发生变化的位置，无需解析完整的方块数据。

分布式协调架构

完成百万格区域的世界下载需要解决三个核心问题：账号管理、网络代理和自动化飞行。

多账号协调：项目使用了 28 个机器人账号同时作业，每个账号配备独立的优先队列订阅。账号通过 BMProxy（一个 Minecraft 代理工具）接入服务器，实现连接复用和流量控制。为避免被服务器反作弊机制检测，账号采用类人类行为模式：随机延迟、非直线飞行路径、模拟自然的视角转动。

自定义下载服务器：团队开发了专用的世界下载服务器（World Download Server），替代客户端直接存储数据。该服务器与代理层配合，实现区块数据的实时接收、校验和写入。相比传统客户端模组直接写入磁盘的方式，专用服务器可以更好地处理并发写入、数据去重和格式转换。

Elytra 自动飞行：项目开发了基于 Pitch40 飞行技术的自动飞行脚本。Pitch40 是一种利用特定俯仰角度实现高效滑翔的技术，相比传统的烟花火箭推进，燃料消耗更低、速度更稳定。自动飞行系统需要处理边界检测、障碍物规避（通过预加载的高度图）、以及断线重连后的位置同步。

归档管道与数据服务

原始数据只是第一步，如何组织、查询和分发这些数据才是真正的挑战。

Wayback Machine 服务：团队部署了基于 PlaceViewer 的服务器（wayback.2b2t.place），允许玩家在游戏中通过指令/fb（flashback）查看任意时间点的世界状态。这一功能类似于网页的互联网档案馆，但实现难度更高 —— 需要实时解压特定时间点的 zvcr 数据并注入游戏世界。

Web 地图查看器：通过 2b2t.place 网站，用户可以浏览器中浏览完整的世界地图。这要求将 zvcr3 格式的 3D 数据实时渲染为 2D 俯视图像，涉及复杂的 LOD（Level of Detail）管理和瓦片生成。

数据挖掘管道：团队开发了专门的数据挖掘程序，用于从 24TB 原始数据中提取有价值的信息 —— 基地位置、玩家活动轨迹、物品分布等。这些分析结果以电子表格形式发布，供社区研究使用。

工程实践与参数建议

对于希望实施类似大规模游戏数据归档的团队，以下参数和经验可供参考：

存储格式选择：如果数据需要长期保存且存在多次采集需求，建议采用支持版本控制的自定义格式。Zstd 压缩级别建议在 12-22 之间权衡，级别 12 适合实时写入场景，级别 22 适合最终归档。

分布式下载策略：账号数量应根据服务器队列机制和 IP 限制确定。2b2t 的案例表明，28 个账号在 109 天内完成百万格区域，平均每个账号每日覆盖约 320 格半径的区域。实际部署时需要预留 30% 以上的冗余时间应对服务器维护、网络中断等因素。

数据校验机制：大规模分布式采集必然存在数据缺失。建议在每个区块附加校验信息（如坐标哈希），并在采集完成后运行完整性扫描，识别并重新下载缺失区域。

分发策略：24TB 级别的数据无法通过常规 CDN 分发。团队计划通过 BitTorrent 协议发布完整数据集，同时提供 Web 服务供轻量级访问。对于存储资源有限的用户，可以提供区域子集或降采样版本。

局限与未来方向

当前 zvcr 格式仅支持 Minecraft 1.20.4 及以上版本，向后兼容性有待完善。此外，24TB 的数据量对大多数研究者和爱好者仍是门槛，团队正在探索更激进的数据压缩方案，如基于机器学习的方块预测编码。

从更宏观的视角看，2b2t.place 项目展示了游戏社区自主保存数字文化遗产的可能性。当游戏服务器由商业实体运营时，社区驱动的归档计划成为保存历史的重要补充。这种分布式、开源、协作的模式，或许可以为其他在线游戏的长期保存提供参考。

资料来源

• 2b2tplace/1m_release: https://github.com/2b2tplace/1m_release
• 2b2tplace/zvcr: https://github.com/2b2tplace/zvcr

systems