缓存策略的改动

做web开发，可能我们现在这个访问量还算不上海量数据（每天pv约是30w），但是之前由于缓存的架构原因，出现了不少问题。cpu一直在70%多，这是个不好的表现，虽然web速度还可以接受，但这总归不是个好的现象。想想造成cpu高的问题吧，本来http就是个比较吃cpu的，之前搜索用的是lucene，这个也特别吃cpu，后来把搜索部署到了其他站点上，情况稍微好了点，但是还不是很理想，所以决定对之前的缓存策略进行调整，以前的缓存在一定程度上浪费了不上空间，而且读取文件次数也不少，io也是造成cpu高的很打原因。所以这次我整理一下系统的缓存，决定先在一定程度上减少缓存文件。

     首先改了用户列表页，采用了array['sourceid']=>array('tag1','tag2')这样子的缓存结构，当时估计这样的结构应对现在的系统比较合适，但是上线后， 并发一下很大，原来情况比料想的要糟糕的多，想办法吧。分析了一下用户列表的情况发现一个问题，就是这种结构对于资源多的用户是极为不适合的。因为，这样会造成缓存文件很大，设想要从一个大的文本文件读取内容的时候，肯定会特别慢。想到这，只能针对这些用户再次修改缓存策略，我是这么做的，之前老大讲过，一个文件在8k的时候应该是操作最快的时候，所以我们只缓存了最新的8k，你要问我，那用户岂不是不能再他自己的列表中看到所有自己的记录了，接下来我把用户剩余的资源做了静态页的缓存，我初步计算了一下，那8k可以存用户最新的最少是60个资源，理论上以前的资源用户是不会动的（这里有点想当然，但是为了保证性能这版先这么干了，以后这块再想办法），所以我把之前的资源做了静态化列表页，这有个好处就是对搜索引擎比较友好。又做了个大的改动就是以前缓存在文件里，现在看了一下大小，把他改到内存了，现在看来速度快了很多。

     cpu也降了一些，另外在这次改动中我发现一点。这个没做过具体的测试，只是感觉。就是当你修改缓存的时候，我发现其实修改了在存，要比删了再build要快。大家如果有分享的经验可以告诉我

     好好总结，再接再厉