扩展大文件下载？

这不是一个坏的架构（ 鱿鱼是一个受欢迎的反向代理），但是，如果你期望指数增长内容交付networking可能是一个更好的解决scheme – 你只支付你需要的内容，带宽即刻（您不必扩大更多的服务器），stream媒体传输是尽可能靠近客户端的服务器，确保他们获得最高的传输速度。 但是，我从来没有尝试过1GB的文件，成本可能是禁止的。

在这种情况下，Torrent技术可以被认为是一个p2p CDN，因此这些提供商中的一些可能适合作为您的内容的种子种子，从而降低您的总带宽成本和（可能）提高速度，尽pipe这取决于您的leechers。

如果您目前没有这样做，那么可能有必要考虑通过BitTorrent将文件传输到服务器上，并将其卸载到P2Pnetworking上。

我的问题是，你怎么知道你是一开始的IO？ 它让我感到奇怪，你的磁盘无法跟上通过HTTP下载（假设这是这种情况，而不是HTTPS）。

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

是否有可能感觉到下载速度缓慢是因为磁盘IO问题，而这可能是Internet带宽问题呢？ （再次，假设这是PI面临的网站）。

有很多方法可以增加磁盘IO – 您可以使用SAN或RAID; 两者都提供了一定程度的caching。 我无法想象任何互联网连接将超过以2Gb / s / hba运行的单个SAN HBA或双SAN HBA（组合）的容量，或者通过具有通过PCI-E总线连接的Cache备份的RAID进行本地存储。

我们是否将Gig-E连接的客户端连接到相同的连接服务器？

你试图在这里扩大你的IO。

使用像squid或varnish这样的caching代理是一种填充caching的方法，以增加主轴而不复制档案中的低/未使用文件。 CDN设备也为你做到这一点。 这些文件是媒体吗？ CDN设备也可以为你做stream媒体。

用户是否经常遇到文件下载失败并重新尝试下载？ 高重试率会大大增加您的IO需求。

你有任何控制如何获取文件？ 一个下载pipe理器可以在不同的块中获取每个文件，从而随着时间的推移将这个请求分成几个块（尽pipe它们也可以并行下载，使你的互联网pipe道饱和）。

作为一个“经验”的参考资料，我只能将所有这些数据放到NAS上（特别是netapp），并且使用NFS来交付文件（尽pipe有很多较小的文件，而不是1GB的文件）。 我们还使用CDN作为caching代理来stream式传输video。

我看到的一种可能的架构使用nginx作为前端，并且由多个Varnish实例支持。 还考虑在该拱上添加二级初级清漆（即清漆从主漆中拉出）。

除此之外，你应该考虑像其他人所说的那样使用CDN。 根据您所服务的（媒体？），有一些专门的CDN更专注于提供大文件，如BitGravity。

你有什么存储系统的数据？ 它能被分割吗？

将物理上不同的SAN上的后端服务器分别与数据的一个子集一起使用，用于反向代理前端机器将在物理上吐出您的数据，并仍然让它们在逻辑上与外部相同。

Nginx的 内存消耗和静态文件服务非常好，因为它可以使用sendfile（）卸载到内核。 Lighttpd也应该看，但我听说它不太稳定（重新消耗内存），但没有使用它。

前端服务器可以通过path或模式来分割后端服务器上的请求（Nginx具有很好的正则expression式支持），甚至可以根据需要redirect到不同的数据中心。 DNS循环也可能有用。

我已经成功地使用Nginx来反向代理，作为慢速同步数据集之间的失败保护。 它会testing该文件，如果它不存在，它会通过HTTP询问后端服务器。 之后它会同步到前端机器，并能正常工作。

确保你监视统计数据。 内存，io等待，带宽，延迟，平均请求时间等。没有监视你所做的是在黑暗中拍摄。

我们所做的是使用MogileFS冗余地存储我们的文件（通过在多个服务器上具有每个文件来实现冗余和可扩展性），但是用户访问通过CDN来获得速度和更好的可扩展性。

我们使用一个更小的CDN，PantherExpress – 它们的定价很好，function集非常好。 当我们逛街的时候，Limelight Networks和EdgeCast也给了我们很好的报价。

我喜欢PantherExpress为你提供了很好的技术文档，你可以获得所有的function，而不是一点点额外的钱。