扩展大文件下载？

Question

我们目前通过单个 Apache 服务器交付大型（1GB+）文件，但是我们的 Apache 服务器受到磁盘 IO 的严格限制，因此我们需要进行扩展。

我的第一个想法是简单地复制这个 Apache 服务器，但是我们的文件库太大，无法简单地水平扩展 Apache 服务器 N 次。

因此，我的下一个想法是在后端安装两个 Apache（高可用性），每个 Apache 都包含整个库的单独副本。然后在前端安装“N”个反向代理，其中“N”会随着我们的交付需求的增长而增长。每个反向代理占用大量 RAM，并且每 GB 有尽可能多的主轴。后端 Apache 服务器更适合“存档”，主轴与 GB 的比率较低。

这是一个好的架构吗？有没有更好的方法来处理它？

Answer 1

这不是一个糟糕的架构（乌贼是一种流行的反向代理），但是如果你期望指数增长内容分发网络这可能是一个更好的解决方案 - 您只需为所需的内容付费，带宽可立即扩展（您不必扩展更多服务器），并且流式传输被定位到尽可能靠近客户端的服务器，确保它们获得最大的传输速度。但是我从未尝试过 1GB 的文件，而且成本可能过高。

在这种情况下，Torrent 技术可以被视为 p2p CDN，因此，这些提供商可能适合作为您内容的 torrent 种子，从而降低您的总带宽成本并且（可能）提高速度，尽管这取决于您的下载者。

Answer 2

如果您目前没有这样做，可能值得研究通过 bittorrent 选择性地传送文件，以将部分负载从您的服务器转移到 P2P 网络上。

Answer 3

我的问题是，您如何知道您一开始就受到 IO 限制？您的磁盘无法跟上 HTTP 下载速度，这让我感到很奇怪（假设这里是这种情况，而不是 HTTPS）。

如果您拥有庞大的用户群，那么 CDN 解决方案似乎很适用，正如其他人指出的那样。我们使用 Akami 进行负载分配。这里的假设是您通过 PI（公共互联网）提供这些文件，而不是仅在 100Mb 或 1000Mb 交换网络上提供某些内部托管解决方案。

您是否有可能将下载速度慢视为磁盘 IO 问题，而实际上它可能是 Internet 带宽问题？（再次假设这是一个面向 PI 的站点）。

增加磁盘 IO 的方法有很多 - 您可以使用 SAN 或 RAID；两者都提供一定程度的缓存。我想不出任何互联网连接能够超过以 2Gb/s/hba 运行的单个 SAN HBA 或双 SAN HBA（组合）或通过 RAID 连接本地存储（通过 PCI-E 总线连接缓存支持）的容量。

我们是在将 Gig-E 连接的客户端与同一个连接的服务器进行讨论吗？

Answer 4

我见过的一种可能的架构使用 nginx 作为前端，并由多个 Varnish 实例支持。还考虑为该架构添加第二级主 varnish（即 varnish 从主 varnish 中提取）。

除此之外，您应该考虑使用其他人提到的 CDN。根据您提供的内容（媒体？），有一些专门的 CDN 更专注于交付大型文件，例如 BitGravity。