主题：【求教】网站的cache，用文件方式实现优还是用数据库方式优？ -- 铁手

西西河的每一个贴，在显示给用户之前，都需要经过一些码式转换，特别是对那些UBB标签，需要把对应的意思表达出来。同时，也需要有一些预处理，以避免恶意代码输入所可能导致的问题。

简而言之，就是用户发贴所输入的内容，和最后显示出来的内容之间需要一道处理。

这个处理，因为访问页面总量的增加，每看一贴就处理一次的效率，相对来说就很糟糕了。

当然，可以把处理后的结果作为一个独立的字段存储起来，只是这样，数据库就会很大。一个是空间的浪费，另一方面也会造成数据库效率的下降。

对最近访问的内容做CACHE是一个办法。可能的方案，一个是利用文件系统，对每个贴写个单独的文件，需要的时候就读取那个文件。或者使用一个表，把所有最近访问的贴放在那里。

这里就要涉及到三个问题。

1、CACHE存储效率

2、读取效率

3、清除过时CACHE的效率 （使用 CRON JOB 来实现，可以不考虑这个因素）

可能归结到最后，就是数据库的索引效率和文件系统的索引效率的差别了。

最终的评估，则是在有大量用户访问的时候，用户端所感受到的页面显示速度。

我现在的做法是使用文件系统。

不过这个做法有些问题，主要是文件数量的问题。1天之内，几十个子目录下就分别有几千个文件。文件数量一多，读写的效率怎样？如果清除CACHE过勤，比如，只保留2天内被访问过的，那么效率是不是也有些低？但是如果保留10天内的，文件数量恐怕会多到让人吃惊。

另外，读写方面，可能也不如数据库，特别是并发操作的情况下。

使用文件系统的好处是在于，所有的CACHE都是在LOCAL的，这个对镜像有利。

使用数据库的一个表的好处是在于可以保证操作过程中的数据一致性。读写效率可能也不错。不利之处是在于远程镜像需要访问远程数据库来得到内容，速度可能会因此降低。同时，数据库的操作本身可能比简单的文件读取效率要低一些？

各位有什么看法，或者有什么参考资料？

1）Pure I/O，文件操作肯定比Database快。所以如果性能是主要考虑的话，我觉得放到数据库里不是一个好主意。另外数据库大了，会拖累其他更重要的操作。

2）Cache到Disk File能省去反复Generate page的过程，但是这么多文件如何管理是个问题。如果你有比较合适的算法，删除文件应该是开销很小的操作。

3）为什么不Cache到内存里。如果一个主体帖大小在10K左右，那么保留3000个帖子在内存理也不过30MB的开销。不算大。你可以设计一个算法，比如3000个帖子之后，新来的帖子将替换掉Cache里相对不重要的帖子（比如说Page view最小，时间最老等等，跟帖最少等等）。

想想还是用文件系统做CACHE算了。旧的文件定期自动删除。

MEMEORY方面的CACHE功能，就交给系统去做了。是有那么个功能的。

就管理和编程来说,数据库比纯文件是要方便太多了

特别是发的帖子，需要每个贴一个唯一编号，如果两边同步的话，估计结果很可能就是互相扯后腿：）

现在的做法是一个中心数据库，每个网站在自己服务器那里有本地的文件作为CACHE，这样就节省了每次看贴时所需要的从数据库到送数据到网站所涉及的资源消耗。