【雷火UX带你聚焦GDC2022】高效、均衡的跨地区数据传输（Activision：Adrian Astley）

网易雷火UX用户体验中心编译，转载需注明本公众号

关于GDC

GDC是全球游戏行业最具规模、最有权威、最有影响力的专业峰会。GDC2022中，雷火UX共获邀17场演讲，分布在9个核心演讲以及8个峰会演讲，再度刷新中国游戏行业纪录，领跑全球。

每年的GDC大会上，全球顶尖的游戏开发者们将齐聚在这里，交流彼此的想法，构想游戏业的未来方向。接下来雷火UX公众号会选择一部分高质量的演讲，陆续为大家进行介绍。本篇为大家介绍的是来自动视公司的工具开发工程师Adrian Astley的演讲“Tools Summit: Efficiently Shuffling Loads of Data from Place to Place ”。

Adrian Astley

Tools & Infrastructure Engineer, Activision

演讲标题：

Tools Summit: Efficiently Shuffling Loads of Data from Place to Place

工具峰会：高效、均衡的跨地区数据传输

演讲者信息：

Adrian于2017年加入电子游戏行业，主要从事开发工具和基础设施管理方面的工作。他开发的工具帮助动视发行了6款《使命召唤》游戏以及旗下其他游戏。

演讲概述：

本次演讲中，Adrian分享的工具Indy，用来进行批量数据传输和分布式构建工作。Indy工具非常成功，已经稳定运行超过4年，覆盖动视几乎所有项目，节约巨大的带宽资源和时间，实现全球化多地协同工作。该演讲对Indy工具进行了全面介绍，并总结了开发和使用过程中的经验教训。

01. 问题描述

动视的游戏开发模式是采用大型分布式开发，特点就是多工作室、多岗位、多地区、多QA站点协作开发，多个LAN网络通过WAN网络进行通信，地理上分布于美国、澳大利亚、上海和欧洲等。目前遇到的问题如下：

跨地区跨机器的数据传输

游戏测试的任务包括编译构建代码，制作游戏数据，运行游戏。这些任务在多台工作机器上并发运行，能更好利用服务器资源，提升测试效率，但同时也带来了服务器之间数据资源的传输问题。

存储过于简单

文件共享服务器最初搭载的是SMB或NFS等文件系统，不具有扩展性。

延迟巨大

如果文件共享服务器放在美国加利福尼亚，其他地区获取文件延迟是巨大的。

下图是不同地区向加利福尼亚文件共享服务器传输1GB文件需要的传输耗时数据。加利福尼亚本地传输只需几秒，其他地区，上传耗时高达几千秒。随着传输延时的增加，带宽也会急剧下降，任何在远端地区工作机上进行的任务会越来越慢，最终将无法使用。

扩展性和容错性

文件共享服务器负载过大，服务器宕机或需要维护或者断电了，需要考虑系统扩展性和容错性。

数据去重

下图的所有任务都需与文件共享服务器进行数据的交互。即使两次任务只有小许修改，都需要再次上传和下载所有数据，这样一来造成很多重复的存储。

同时游戏数据量非常大。假设每小时有10次代码提交，每次需构建3张地图，数据大小约为70GB，目前需要给5个平台（PC,XB3,XB4,PS4,PS5）进行编译，那么每小时的数据量84TB。如果需要测试3张地图，每张地图做2次测试，那么每小时测试的数据量是21TB，一天就是504TB。

数据需清理

不清理是不可能的，因为数据实在太大。如果通过脚本遍历文件进行清除，遍历操作随着文件系统不断变大而陷入死循环。

02. 历史做法存在的问题以及如何提升

历史的一般做法是使用多种开源或者内置的工具进行数据传输，这样很混乱，没有完整的系统，过程中也存在很多问题。

历史做法及存在的问题

● 打包工具包括一些安装程序，压缩工具和Docker系统。安装程序，如linux的.deb/.rpm, 是将一组文件通过脚本进行组合安装，有些安装程序会只复制不存在的文件，但都没做下载的去重检查，每次下载都需要下载全部安装包。压缩工具，如zip/tar/7zip等，不会做数据去重。Docker系统有不错的文件隔离和重复数据删除属性。

● 数据传输工具，有很多开源的和内置的工具，如微软robocopy。这些工具只需提供源目录和目标目录就可以并发地、快速地进行数据传输。文件比对通过比较文件大小和时间戳等，并不是百分百准确。最佳的比对方式是基于内容的Hash值比对。为了计算Hash值就必须去共享服务器上下载文件，需要用户去鉴别文件是否重复。

以上的工具都是基于文件系统的基础上使用，不具备可扩展性。

如何提升

首先，要明确提升的目标：

● 简单二进制的客户端工具；

● 基于数据块的数据去重功能；

● 自动清除无用数据；

● 系统组件垂直可扩展，具备容错性，尤其是数据存储方面；

● 能充分借鉴和利用开源工具和社区资源。

基于这些目标，需要做的事情如下：

● 本地命令行输入终端，用户可输入命令进行操作，命令语句明确且易用，能使用脚本运行；

● 能把文件上传到远端的服务器。因为文件共享不是很好的方式，所以可选择HTTP对象存储作为文件服务器；

● HTTP是高度可扩展的，可跨平台，有丰富的工具和完善的基础设施；

● 需要一些服务器的组件，专门用于数据去重和数据清理等。

03. Indy工具的全面介绍

Indy工具包括二进制客户端indy，元数据服务器Ark，云对象存储服务器WebDAV，使用Golang来开发工具和服务器组件。Indy通过Image来组织所有的数据资源。Image包含文件包，ENV变量，以及处理文件/变量的命令操作。

图示的系统有客户端A和B，Ark元数据服务器，以及对象存储服务器。第一步，Client A通过“Indy build”命令创建一张Image，并且它想要共享这张Image。接下来，Client A通过‘Indy push’命令，会告诉Ark需要上传的数据，然后Client A并发上传构建的图到对象存储服务器。Client B通过“Indy pull”命令进行下载，告知Ark需要下载的数据，然后从对象存储服务器下载。下载下来的图像是不能直接使用的，需要用“Indy mount”命令加载为一个Image对象才可以使用。

图像的构建需要创建IndyFile文件(下图左)，利用自定义语言对图像的内容进行定义。自定义语言如“Add”指令是添加文件，“CHUNK”指令是切割文件。有了IndyFile之后，就可调用“Indy build”命令。Indy工具会读取IndyFile中的指令，并运行指令创造一张Image。Build命令会输出一串Sha1哈希串，用于唯一标识Image。通过Sha1值去引用图像是不方便的，所以通过创建一个可读性友好的标签（Label），作为一个指针来引用Image，标签格式如下图右。

命令“Indy build“运行IndyFile的指令生成一张Image的内容清单，如下图。图像清单是JSON文件，列出了所需的文件，每个文件包含了文件块的Sha1值和大小。

如上所述，标签是一个可读性友好的指针，用来引用图像，如下图标签为aastley/gdc-test:v1，它指向图像obff1。因为标签是指针，所以可添加任意数量的标签来引用同一张图。“Indy images”命令可查看本地所有图像。标签可设置TTL（Time to Live），代表标签的过期时间。

当TTL到来时，运行“gc”命令进行垃圾回收。Indy的引用层次结构如下所示。最上层是标签，顶层标签都指向一个特定的图像。各图像指向包含的文件块。需注意的是，文件块可以被多个图像所共用。

垃圾回收有3个阶段。第一阶段是检查标签TTL是否过期，过期就删除，如下图标签aastley/my-awesome-label:123。

第二阶段是检查所有图像，未被任何标签引用的图像可删除。图obbf149和f1d2d2f皆有标签引用，所以无需删除。

第三阶段，对所有文件块的引用数进行计数，文件块的引用数为0表示没有被应用，可删除。

“Indy push”命令用来进行数据上传，告知Ark需要上传的数据，Ark会查询数据库找到对应的文件块，再把查询结果返回给客户端。Indy客户端只上传Ark查询缺失的文件块到云存储服务器。Indy最后会发送一个POST请求给Ark，告知上传成功。Indy只会上传缺失的文件块，因此大大节约了带宽资源。

Indy客户端通过标签向Ark获得图像的Sha1值，通过这个值去对象存储服务器上获得IndyFile。Indy比对IndyFile和本地已有的文件块信息，计算出本地没有的文件块。Indy调用pull命令从对象存储服务器并发下载本地缺失的文件块，有效节约带宽资源。

对于缓存系统来说，由于文件是基于内容的Sha1哈希串来标识，所有文件都是不可变的，不存在缓存的一致性问题。下图的系统有中央对象存储器，每个工作室有专门的缓存节点。所有客户端内部的下载和上传操作都通过缓存节点，客户端无需连接中央对象存储器。这个模式的优点如下：

● 缓存节点缓存文件，工作室内所有客户端通过LAN从缓存节点下载数据，减少WAN带宽，降低对象存储器的负载压力。

● 缓存节点是可控的，可做更有效的专门调整来保障WAN流量尽可能优化。

● 缓存节点是可扩展的，通过增加缓存节点提高负载能力，增加容错性。多缓存节点下，遇到缓存节点维护或挂了，客户端仍可使用其他在线服务的节点。

另外，如何来确定文件块的大小呢？演讲者分享了一个实验，创建不同大小的文件，分别放到两个基本一样的nginx服务器。一个nginx服务器是20Gbps网卡，另一个是40Gbps网卡。每个文件下载1000次，测算下载速度。当文件块大小只有100KB时，吞吐量很低。即使是40Gbps的网卡，也只能到达约8Gbps的带宽。