分类: LINUX
2008-04-25 15:28:45
缓存的命中率
一个缓存的实体在被丢到缓存中后,在这个实体被缓存的期间(这个实体被缓存的生命周期内),如果外部一次都没有使用过它,这个缓存实体的命中率就是0。这个实体被请求的次数越多,它的缓存命中率越高。
上面说的是缓存中一个实体的命中率。对于缓存整体来说,它的命中率则是上面各个被缓存的个体的命中率分布图。
对于缓存来说:通常最常使用的个体之占总体的很小一部分。最不常使用的占整体的很大一部分。如下图所示:
所以我们经常会看到类似这样的数据:
缓存的1万个元素中,有100个被频繁的使用,几乎每分钟都会被使用一次。2000个数据,每小时被请求一次。3000个数据,每天被请求一次,剩下的数据,被丢到缓存中后一次都没有被使用过。
现在硬件发展很快,如果我们只是需要缓存1万个数据的话,我们完全可以做到不管这1万个数据是否被使用到,全部丢到缓存,这样只要找数据,肯定缓存中有这个数据。而不需要作额外的运算,或者不需要向数据库发出请求。
但是:硬件发展快,数据量发展也快。小型的网站,缓存1万条数据,也就全部缓存了。但是大型网站最少也是上百万的数据量或者上T级别的数据,这些数据量显然不能都丢到缓存。这时候设计一个合理的缓存方案,提高缓存的命中率,就非常重要。而且是必须的。
提高缓存命中率的一些常见方法
纯技术的角度来说,我们只有记录了用户的单位时间的请求数,并依照这个信息来把最常被使用的数据缓存起来。
但更多的时候,我们是根据业务逻辑来提高缓存命中率的。比如:去年,前年发表的博客,这类文章的浏览请求,一般一天至少可怜的几次。一般不应该缓存到内存中。
又比如,回复数多的帖子,一般被请求数会比回复数少的帖子会被更多人次看到。
我们应该通过上面逻辑,根据我们实际业务逻辑,提供一个缓存算法,提高缓存的命中率。让在我们硬件允许的条件下,缓存适当的数据,而不是所有数据。
一个反面的例子就是:不管三七二十一,一个大型的博客站点,一篇文章被用户请求的时候,发现不在内存缓存中,就从数据库中读出,然后丢到缓存。
要知道,现在爬虫程序很多的。另外,博客这类搜索引擎友好的站点,决大多数的访问压力是搜索引擎搜索过来的。而这些访问一般都是1小时,或者1天之内,对某篇文章只有几次甚至1次请求,之后再也没有了。上面作缓存的方法,命中率会非常低的。
如何提高我站点的性能.至少得保证博客站点不会速度慢的无法响应用户请求呀。
这个问题的解决方案有很多,一个最简单的方法就是把这些博客做成静态Html页面,也就是文件系统的缓存,文件系统因为硬盘的原因,可以简单理解成可以无限扩容,这样就可以把很多命中率低的内容进行缓存。
如果你的页面需要一些动态逻辑判断,你可以把数据缓存成XML文件,然后服务器段整合这些XML文件,或者是包含文件。这也是种不错的方法。
说了这么多缓存命中率的问题,简单汇总一下缓存命中率的观点:
下面我们看看缓存的其他几个不那么重要的方面:
缓存的生命周期内的活动
永久不过期,永久不变更的内容,这类东西就不应该放在缓存。缓存是临时的存储,而不是永久的,所以缓存的生命周期是有限的。
它依次可能会经历如下活动:
缓存的过期策略
最常见的几种过期策略如下:
多长时间没有被请求,则过期,最典型的就是ASP和ASP.net 提供的 Section 功能。其实它就是一个缓存。
依赖于文件变更的缓存,一旦文件被修改,缓存则过期,典型的是 WEB站点的 Web.config ,一旦这个文件变更,不但缓存重起,IIS进程也会进行一次释放工作。
在此基础上,可能看到很多依赖关系的缓存过期策略。比如依赖于数据库的缓存过期策略。
当然,业务逻辑里可能会有更复杂的过期策略,必须CSDN新版积分制论坛中,帖子列表缓存会在列表数据缓存达到600时,把它清理到550条数据。
又比如新积分制论坛帖子的缓存过期,则是没有任何列表引用这个帖子后,则这个帖子过期。
缓存的同步问题
使用缓存,则意味着同样的数据,可能有多份并存。如果你的代码没有考虑某种情况,导致了这两份数据不一致了。这时候就会有问题发生。
解决方法很简单,把你的业务逻辑,代码触发情况都考虑清楚,不要遗留没有触底的地方。
简单的方法会导致你的代码逻辑变得非常复杂。
这也就是有些人,在非必要的时候,建议你不要用缓存的原因。一旦开始使用缓存,你就应该准备增加大量的代码来处理数据同步的问题。
初始化填充缓存数据
有时候在缓存被初始化后,还需要预先填充一些数据到缓存中。这就是缓存数据的初始化操作。
缓存数据的初始化操作需要考虑以下问题: