我的主要目标是通过网络服务器提供大量的XML文件（每个＆lt; 1kb大于10亿）。文件可以被认为是staic，因为它们将被外部代码修改，频率相对非常低（每天大约50k更新）。将以高频率（> 30 req / sec）请求文件。
我团队目前的建议是创建一个专用的Java应用程序来实现HTTP协议，并使用memcached来加速这个事情，将所有文件数据保存在RDBMS中并摆脱文件系统。
另一方面，我认为，调整后的Apache Web Server或lighttpd就足够了。缓存可以留给操作系统或Web服务器的默认缓存。如果需要相同的输出并且仅根据文件名查询，则在DB中保留数据没有意义。不确定memcached如何在这里工作。同时通过外部代码更新文件时更新外部缓存（memcached）会增加复杂性。
另外一个问题，如果我选择使用文件，是否可以将它们存储在\ a \ b \ c \ d.xml目录中，并通过abcd.xml访问？或者我应该将所有1bn文件放在单个目录中（不确定操作系统是否允许）。
这不是一个网站，而是封闭网络中的应用程序API，因此Cloud / CDN没用。
我打算使用CentOS + Apache / lighttpd。建议任何替代和最佳解决方案。
This是关于此类主题的唯一公开说明，它也不太老。
答案 0 :(得分：3)
每个1KB的1bn文件，大约是1TB的数据。令人印象深刻。因此除非你有非常昂贵的硬件，否则它不适合内存。如果你的文件系统为小文件浪费了大量空间，它甚至可能是磁盘上的一个问题。
每秒30次请求远没那么令人印象深刻。它当然不是网络的限制因素，也不是任何严肃的网络服务器。对于缓慢的硬盘来说，这可能是一个小挑战。
所以我的建议是：将XML文件放在硬盘上，并使用您选择的普通香草Web服务器为它们提供服务。如果每秒不能达到50个文件，则测量吞吐量并对其进行优化。但除非你已经证明这是一个限制因素，否则不要投入任何东西。
可能的优化是：
如果每天多次请求大量文件，那么即使是慢速硬盘也应该足够，因为您的操作系统会将文件放在文件缓存中。使用今天的文件缓存大小，您每天的大量交付将适合缓存。因为每秒30个请求，您最多每天服务0.25％的所有文件。
关于在多个目录中分发文件，可以使用Apache RewriteRule 隐藏它，例如：
RewriteRule ^/xml/(.)(.)(.)(.)(.*)\.xml /xml/$1/$2/$3/$4/$5.xml
答案 1 :(得分：1)
你可以看到的另一件事是Pomegranate，它看起来与你想要做的非常相似。
答案 2 :(得分：0)
我相信一个专门的应用程序，所有东西都从memcache数据库中获取，这将是最好的选择。