我为一个视频搜索网站编写了一个非常快速且肮脏的缓存系统，该系统将 bing 搜索结果 gzip 压缩并缓存在隐藏的“/cache/”目录中。
最初几个月一切都进展顺利，直到我开始注意到非常受欢迎的搜索结果没有显示任何视频。
我查看了缓存文件夹，果然，它充满了大约 30,000 个缓存文件，其中许多文件都是在创建时没有任何内容……甚至对于非常流行的搜索词也是如此。
我删除了大约 10,000 个缓存文件（超过 1 个月，或者结果是空的），现在一切似乎又恢复顺利了。
显然，我将不得不在不久的将来编写一个合适的 MySQL 缓存系统，但是一个目录中的这么大量的文件是否会导致 CentOS 出现故障？
也许提取缓存文件并解压它实在是太多了？
我有一个机制，每当下载不顺利时都会警告我。bing 服务器并没有阻止我，我确实得到了结果，只是当缓存文件夹中的文件数量“太大”时，我（偶尔）无法缓存它们。
欢迎提出所有想法/评论！
答案1
这取决于您使用的文件系统类型。例如，我相信 ext2 和 ext3 限制为 32000 个子文件夹（您可以拥有这么多或更多文件，但性能会受到影响……）；ext4 是这个数字的两倍，而其他一些文件系统允许更多或无限数量。请参阅Server Fault 上的这个问题以进行涉及各种 Linux 文件系统类型的讨论和解答。
答案2
我在 FC7 和 Ubuntu 上看到了相反的情况，目录处理超过 100K 的文件没有问题。相反，当子目录的数量达到 32K 或更多时就会出现问题 - 但不仅仅是文件。
既然您说这个解决方案“非常快速和肮脏”，那么问题可能不在于 CentOS，而在于您的代码？或者甚至在于您使用的语言？您的代码是否可能试图同时打开所有这些文件，从而耗尽文件句柄或某些此类资源？
答案3
真正的答案与 Bing 的劣质 API 有关 - 请参阅官方 bing API 2.0 论坛上的此主题：http://www.bing.com/community/Developer/f/12254/t/662869.aspx
基本上，他们会随机隐藏随机搜索查询的结果 - 迫使您以两倍于要求的力度访问他们的服务器，才能从他们那里获取信息。由于很多时候“无结果”的响应实际上有结果，因此您必须再次检查。
感谢大家的意见！