我正在考虑将 bittorrent 用于数据源为 PB 级且用户需要高达数 TB 的大型数据传播问题。一些细节
我预计与可用种子总数相比，活动种子的数量会很小，但服务质量很重要，因此每个种子必须有几个播种机或启动新播种机的某种机制。
我的问题是，bittorrent 客户端能否处理大量种子种子，其中大部分是空闲的？我是否需要在集群中的播种机上对种子进行条带化，或者每个节点是否可以播种它可以访问的所有种子？哪个客户会做得最好？有没有管理播种机集群的工具？
我假设跟踪器可以扩展到这个级别。
有2个主要问题：
至于跟踪器流量，假设您有 100 万个种子，典型的重新发布间隔为 30 分钟，但某些跟踪器将其设置为 1 小时。让我们保守一点，假设您的跟踪器使用 1 小时宣布间隔。您必须每小时发出 100 万个 GET 请求，假设每个请求向上 400 字节，向下 100 字节（假设大多数响应不包含任何对等点），大约 111 kB/s 向上和 28 kB/s 向下不断。这还不错，但请记住，TCP 需要额外的往返来建立连接，因此又要减少 40 字节和增加 40 字节。
这可以通过仅使用UDP 跟踪器来缓解。那么您只需要一个连接消息，并且您可以为每个通知重用连接 ID。然后每个宣布消息将是 100 字节，返回的消息也会更紧凑，假设 60 字节。这将使您的速度提高 28 kB/s，降低 16kB/s，只是为了让种子保持公布。为此，您需要一个具有良好 udp 跟踪器支持的客户端（例如缓存连接 ID 的客户端）。
还不错，假设与您的种子发送的实际数据相比，这微不足道。
但是，您不一定需要将种子分散到不同的数据中心，您也可以使用 HTTP 服务器来播种种子。所有主要的 bittorrent 客户端都支持 http 播种，您不必担心向跟踪器宣布（URL 被烧录到 .torrent 本身）。
至于可以很好地扩展种子的客户端，我不确定，我没有做过任何测量。生成一百万个随机种子并尝试加载它应该是相当简单的。
我在libtorrent rasterbar中做了一些优化工作，以使其能够很好地适应许多种子，但我还没有尝试过数百万。
我已经写了一篇关于这个主题的博文，在这里。
您可能正在寻找Hekate 它现在充其量处于 pre-alpha 阶段，但它与您所描述的非常接近。
为了在数百万次无用的跟踪器宣布和刮擦（以及在每个宣布间隔内）的开销下不崩溃，您必须限制播种集群仅加载当前请求的当前工作项目集。无论如何，下载者都需要从中心位置获取（下载）.torrent 文件，这可能会触发将其加载到播种集群中。或者，通过识别不是来自您的种子集群之一的公告来确定特定信息散列的活动。
rTorrent 具有快速恢复（意味着在加载适当准备的 .torrent 时不会发生散列），并且可以通过 xmlrpc 进行控制，因此您可以停用空闲项目。这样，.torrent 下载可以触发实际数据在接下来的 24 小时内可用，或者只要群体中有活动。
该协议允许这样做，但我不知道哪些客户端可以扩展到数百万个种子。在最坏的情况下，您将不得不编写自己的纯种子客户端。
与您的用例最相关的协议功能是，当一个对等点连接到另一个对等点时，连接的对等点应该首先发送 torrent 的信息哈希。这意味着单个侦听 TCP 端口可用于播种无限量的种子，空闲时使用的资源几乎为零。
这可以在BitTorrent 协议规范中找到：
如果双方不发送相同的值，他们将切断连接。一个可能的例外是，如果下载者想要通过单个端口进行多次下载，他们可能会等待传入连接首先给出下载哈希，如果它在他们的列表中，则使用相同的响应。
我也在这个Bittorrent 协议规范 v1.0上找到了相同的内容：
连接的发起者应该立即发送他们的握手。如果接收者能够同时提供多个种子（种子由其 info_hash 唯一标识），则接收者可以等待发起者的握手。
但是，有一件事会增加您的负载，那就是跟踪器。使用正常的跟踪器协议，每个客户端都必须定期向跟踪器宣布它拥有的每个种子，以及它上传了多少等信息。对于数以百万计的洪流，这将带来一些高负载。如果您正在编写自己的仅限大量种子的客户端，那么一个单独的协议将您的播种器宣布给跟踪器将是一个好主意。