使用bittorrent协议分发夜间构建和CI构建
本文关键字：构建 CI bittorrent 协议 使用 | 更新日期: 2023-09-27 18:08:02
这个问题延续了我昨天问的题为"使用git发布夜间构建"的问题。
在上述问题的答案中，很明显git不适合我的需要，并鼓励我重新检查使用BitTorrent。
短版
需要每天早上将夜间构建分发给70多人，希望使用gitBitTorrent来负载平衡传输。
NB。如果你读过我上一个问题，你可以跳过下面一段。
每天早上，我们需要将我们的夜间构建分发给70多人的工作室(美术人员，测试人员，程序员，制作人员等)。到目前为止，我们已经将构建复制到服务器上，并编写了一个同步程序来获取它(在下面使用Robocopy);即使设置了镜像，传输速度也慢得令人无法接受，在高峰时间(非高峰时间大约为15分钟)需要长达一个小时或更长时间才能同步，这表明存在硬件I/O瓶颈和可能的网络带宽。
我所知道的
到目前为止我发现了什么:
我在维基百科上找到了关于BitTorrent协议的优秀条目，这是一个有趣的阅读(我以前只知道基本知识种子如何工作)。在客户端-服务器握手后发生的BITFIELD交换中也发现了这个StackOverflow答案
我还找到了MonoTorrent c#库(GitHub源)，我可以用它来编写我们自己的跟踪器和客户端。我们不能使用现成的跟踪器或客户端(例如uTorrent)。
在我最初的设计中，我让构建系统创建一个。Torrent 文件和添加到跟踪器。我将使用我们现有的构建镜像来超级种子种子。使用这种设计，我需要创建一个新的。Torrent 文件为每个新构建?换句话说，是否有可能创建一个"滚动"。Torrent 如果构建的内容只有20%的变化，这是所有需要下载到获得最新的?
…实际上。在编写上述问题时，我认为我需要创建新文件，但是我将能够下载到用户机器上的相同位置，并且哈希将自动确定我已经拥有的内容。这是正确的吗?
回应评论
为了完全同步整个构建(包括:游戏，源代码，本地化数据和PS3和X360的光盘映像)~37,000个文件，不到50GB。随着生产的继续，这一数字将会增加。这个同步花了29分钟完成，而此时只有2个同步在进行，如果你考虑到在上午9点，我们将有50多个用户想要获得最新消息，这是一个低峰值。
我们与IT部门调查了磁盘I/O和网络带宽;结论是网络存储已经饱和。我们还将统计数据记录到同步数据库中，这些记录表明，即使只有少数用户，我们的传输速率也无法接受。
关于不使用现成的客户端，在用户的机器上安装像uTorrent这样的应用程序是一个法律问题，因为其他项目可以很容易地使用该程序下载。我们还希望有一个自定义的工作流来决定你想要获得哪个版本(例如，只有PS3或X360取决于你桌上的DEVKIT)，并有新版本可用的通知等。使用MonoTorrent创建客户端不是我关心的部分。
对于是否需要创建一个新的.torrent的问题，答案是:是。
然而，根据你的数据布局，你可以做一些简单的半增量更新。
如果您分发的数据是单个文件的大集合，每次构建一些文件可能会发生变化，您可以简单地创建一个新的.torrent文件，并让所有客户端将其下载到与旧文件相同的位置(就像您建议的那样)。客户机将首先检查磁盘上已经存在的文件，更新已更改的文件并下载新文件。主要的缺点是被删除的文件实际上不会在客户端被删除。
如果你正在编写自己的客户端，那么删除文件系统中.torrent文件之外的文件是一个相当简单的步骤，可以单独完成。
如果您分发一个图像文件，这不起作用，因为在不同版本之间保持不变的位可能已经移动，从而产生不同的散列。
我并不一定推荐使用超级播种。根据您使用的超级播种实现的严格程度，它实际上可能会损害传输速率。请记住，超级种子的目的是最小化从种子发送的字节数，而不是最大化传输速率。如果你所有的客户端行为正常(例如，使用rarest优先)，块分布无论如何都不应该是问题。
此外，创建一个torrent并对一个50 GiB的torrent进行哈希检查会给驱动器带来很多负载，你可能想要对你使用的bittorrent实现进行基准测试，以确保它的性能足够好。在50gib时，不同实现之间的差异可能是显著的。
只是想添加一些非bittorrent的建议供您阅读:
-
如果每晚构建之间的差值不是很大，您可以使用rsync来减少网络流量并减少复制构建所需的时间。在之前的一家公司，我们使用rsync向发行商提交构建版本，因为我们发现我们的光盘映像在构建到构建之间没有太大的变化。
-
您是否考虑过简单地交错复制操作，以便客户端不会减慢彼此的传输速度?当我们进行里程碑分支时，我们一直在内部使用一个简单的Python脚本:脚本进入休眠状态，直到指定范围内的随机时间，然后醒来，下载并签出所需的存储库并运行构建。用户在离开工作时运行脚本，当他们返回时，他们已经准备好了所有内容的新副本。
你可以使用BitTorrent sync，这在某种程度上是dropbox的替代品，但没有云服务器。它允许您同步任何数量的文件夹和任何大小的文件。它使用与bit Torrent协议相同的算法。您可以创建一个只读文件夹，并与他人共享密钥。这种方法消除了为每次构建创建新的torrent文件的需要。
再给你一个选择，你考虑过BITS吗?我自己没有使用过，但是从阅读文档来看，它支持分布式对等缓存模型，听起来它会实现你想要的。
缺点是它是一个后台服务，所以它会放弃网络带宽，支持用户发起的活动——这对你的用户来说很好，但如果你需要在一台机器上快速获取数据，可能就不是你想要的了。
不过，这是另一种选择。