应该使用哪种技术来提供大量静态文件？答案

【问题标题】：Which technology should be used for serving large number of static files?应该使用哪种技术来提供大量静态文件？
【发布时间】：2010-08-27 18:41:34
【问题描述】：

我的主要目标是通过 Web 服务器提供大量 XML 文件（> 10 亿，每个 30 req/sec）被请求。

我的团队目前的建议是创建一个专用的 Java 应用程序来实现 HTTP 协议并使用 memcached 来加快速度，将所有文件数据保存在 RDBMS 中并摆脱文件系统。

另一方面，我认为，经过调整的 Apache Web 服务器或 lighttpd 就足够了。缓存可以留给操作系统或 Web 服务器的默认缓存。如果需要相同的输出并且仅根据文件名进行查询，则将数据保留在 DB 中是没有意义的。不确定 memcached 将如何在这里工作。在通过外部代码更新文件的同时更新外部缓存（memcached）也会增加复杂性。

还有其他问题，如果我选择使用文件，是否可以将它们存储在 \a\b\c\d.xml 等目录中并通过 abcd.xml 访问？或者我应该将所有 10 亿个文件放在一个目录中（不确定操作系统是否允许）。

这不是网站，而是封闭网络中的应用程序 API，因此 Cloud/CDN 没有用处。

我打算使用 CentOS + Apache/lighttpd。建议任何替代和最佳解决方案。

This 是在该主题上找到的唯一公开注释，而且它也有点旧。

【问题讨论】：

每天 50k 更新是每 2 秒更新一次。这不是我所说的“低频”更新。
但与记录/文件总数相比，频率相对较低。
没关系，在那个速度下，任何基于磁盘的东西都会产生明显的效果。记在心里。

标签： apache static memcached webserver lighttpd

【解决方案1】：

10 亿个文件，每个 1KB，大约是 1TB 的数据。感人的。因此，除非您拥有非常昂贵的硬件，否则它将不适合内存。如果您的文件系统为小文件浪费了大量空间，这甚至可能是磁盘上的问题。

每秒 30 个请求远没有那么令人印象深刻。这当然不是网络的限制因素，也不是任何严肃的网络服务器的限制因素。对于慢速硬盘来说，这可能是一个小挑战。

所以我的建议是：将 XML 文件放在硬盘上，并使用您选择的普通 web 服务器为它们提供服务。然后测量吞吐量并优化它，如果你没有达到每秒 50 个文件。但是，除非您已经证明这是一个限制因素，否则不要投资任何东西。

可能的优化有：

在文件系统中找到更好的布局，即将文件分布在足够多的目录中，这样单个目录中的文件就不会过多（超过 5,000 个）。
将文件分布在多个硬盘上，以便它们可以并行访问文件
使用更快的硬盘
使用固态磁盘 (SSD)。它们价格昂贵，但每秒可以轻松处理数百个文件。

如果每天多次请求大量文件，那么即使是速度较慢的硬盘也应该足够，因为您的操作系统会将文件保存在文件缓存中。并且以今天的文件缓存大小，您每天交付的大量文件都可以放入缓存中。因为每秒 30 个请求，您每天最多提供 0.25% 的文件。

关于将文件分布在多个目录中，您可以使用 Apache RewriteRule 将其隐藏，例如：

RewriteRule ^/xml/(.)(.)(.)(.)(.*)\.xml /xml/$1/$2/$3/$4/$5.xml

【讨论】：

@Codo：我没有将“bn”翻译成“billion”。
正是我的想法——在上面构建一个应用程序只会让它变慢。一个非常重要的问题是延迟 - 没有“网络服务器的默认缓存”，但是发布更新的延迟越长，通过网络服务器缓存可以服务的负载就越多。
你也可以使用 NginX，然后使用内置的正则解析将文件放入子目录。在这个数量的文件中，在股票文件系统（例如 ext3）上几乎需要将它们分成多个级别的子目录
我目前正在测试 Codo 的实现。到目前为止，没有问题，因为存在的数据非常少。但我认为这应该有效。除了 RewriteRule，我还为不存在数据的请求实现了 ErrorDocument 404 以发送罐装回复。在这种情况下，我不确定如何将响应代码从 404 更改为 200。让我知道这是否可能在不涉及 PHP 的情况下通过 Apache 配置实现。
要将错误代码从 404 更改为 200，您基本上在 Apache 配置中使用两个指令：“RewriteCond %{REQUEST_FILENAME} !-f”和“RewriteRule ^.*+ /dummy_reply.xml” .第一个确保第二个仅适用于无法将请求解析为现有文件的情况。第二个访问预设回复。

【解决方案2】：

您可以查看的另一件事是Pomegranate，这似乎与您尝试做的非常相似。

【讨论】：

【解决方案3】：

我相信最好的选择是使用所有内容都来自 memcache 数据库的专用应用程序。

【讨论】：

我不认为 memcache db 会产生奇迹，因为 memcache 命中率会非常低，一旦数据开始超过缓存大小（受可用 RAM 限制），事实上，更多将是更新缓存以与持久存储同步以及检查每个可能的命中/未命中请求的负担。我更倾向于 Codo 建议的 lighttpd 和结构化文件系统，但我可能错了。这里的优点是操作系统将保留一个缓存，如果文件被外部进程更新，它将从缓存中删除文件。需要测试这两种方法。