漫谈应用缓存的命中率有关问题

这篇文章源自于：

http://www.iteye.com/topic/77195

其中很多人谈到了缓存命中率的问题，应用缓存的命中率取决于很多的因素：

1、应用场景
是OLTP还是OLAP应用，即使是OLTP，也要看访问的频度，一个极少被访问到的缓存等于没有什么效果。一般来说，互联网网站是非常适合缓存应用的场景。

2、缓存的粒度
毫无疑问，缓存的粒度越小，命中率就越高，对象缓存是目前缓存粒度最小的，因此被命中的几率更高。举个例子来说吧：你访问当前这个页面，浏览帖子，那么对于ORM来说，需要发送n条SQL，取各自帖子user的对象。很显然，如果这个user在其他帖子里面也跟贴了，那么在访问那个帖子的时候，就可以直接从缓存里面取这个user对象了。

3、架构的设计
架构的设计对于缓存命中率也有至关重要的影响。例如你应该如何去尽量避免缓存失效的问题，如何尽量提供频繁访问数据的缓存问题，这些都是考验架构师水平的地方。再举个例子来说，对于论坛，需要记录每个topic的浏览次数，所以每次有人访问这个topic，那么topic表就要update一次，这意味着什么呢？对于topic的对象缓存是无效的，每次访问都要更新缓存。那么可以想一些办法，例如增加一个中间变量记录点击次数，每累计一定的点击，才更新一次数据库，从而减低缓存失效的频率。

4、缓存的容量和缓存的有效期
缓存太小，造成频繁的LRU，也会降低命中率，缓存的有效期太短也会造成缓存命中率下降。

所以缓存命中率问题不能一概而论，一定说命中率很低或者命中率很高。但是如果你对于缓存的掌握很精通，有意识的去调整应用的架构，去分解缓存的粒度，总是会带来很高的命中率的。

这里我可以举一个实际的案例，JavaEye2.0网站在使用对象缓存之前，通过MySQL的监控工具进行观察，在连续24小时的平均每秒发送SQL条数超过了200条，在使用对象缓存之后，连续24小时的平均每秒发送SQL条数下降到了120条左右，几乎下降了一半。

考虑到很多SQL都是分页语句，关联查询，条件查询，集合操作，都是不能被缓存的SQL，而真正能够被缓存的SQL只有根据主键查询对象和对象关联对象的查询。所以真正能够被缓存的SQL估计最多占所有SQL的60%。所以换算下来，应用缓存的命中率之高，已经相当惊人了。

不过这里要提醒的一点，有将近一半的SQL都被缓存，不意味着性能可以提升一倍。这是因为能够被缓存的都是按照主键查询单条记录的SQL，这些SQL本身即使发送到数据库，对数据库造成的压力也没有想像的那么大。真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。当然了，不管怎么说，通过使用对象缓存，是毫无疑问可以大幅度降低数据库的负载压力的，有效提升web应用的性能的。

关于这一点，我再给出一组数据来加深大家的印象，通过使用操作系统网络工具进行统计：

JavaEye网站web server的端口每秒数据流量是2MB；
JavaEye网站的MySQL数据库端口的每秒数据流量是1.2MB；
而网站的memcached的端口每秒的数据流量高达5MB。

5 楼 抛出异常的爱 2007-05-09  

你这样的人还是少数。

6 楼 chenqj 2007-05-09  

对象 缓存是基本的
对于很多 应用，查询 缓存才是最关键的
尤其对web这种列表 应用

7 楼 Readonly 2007-05-09  

janh 写道

不认为这是无太大用处的功能，我就经常点中间的页数，如果第一次看这个帖子时只有4页，过了几天达到8页了，那我显然直接从第4页看起，一次一次点下一页岂不是麻烦，而且更浪费服务器资源，有时要看谁在第几页的发言当然也是直接点页数。

偶是指不要把那么页数显示在分论坛的帖子列表中，在进入单个帖子的页面当然还是需要的。
另外，偶的小脑袋哪能记住几天前看到第几页这种OOXX的事情，还要记住谁在第几页的发言简直是@#￥%...这种大肠帖都是点开最后一页，然后依靠回复时间来找到大致位置

8 楼 yfmine 2007-05-09  

robbin讲的都是对象 缓存，想冒昧请问一下，javaeye使用了页面 缓存吗？对于页面 缓存，那么是算作粗粒度还是细粒度呢？这样做的也应该可以控制到比较高的 命中率吧，和对象 缓存相比，两者各有什么优劣，或者说两者一起使用是否能够做到比单纯的对象 缓存更好呢？

在我们做过的一个web项目中，是通过模版生成伪静态页面，说它是伪静态，是因为这个页面本身也是一个模版，在生成最终页面呈现给用户时，会填入一些动态的数据，就比如这个论坛的投票数量什么的。相当于磁盘 缓存了，但这个是 应用服务器的本地磁盘，速度上很快，而且避免了服务器之间的网络通信。比如论坛里每个帖子的文章内容，不需要再去数据库或者 缓存里取，这样是不是能减少与memcached通信的流量呢。

web 应用多数都是查询大于数据操作，那么cache用于解决性能是屡试不爽，但是对于插入，更新频繁的企业 应用，一般是应该从哪方面去解决的呢。

另外，想请教下对于新闻发布系统那种纯静态页面，apache有没有什么模块，可以判断静态页面是否存在，如果不存在，才给 应用服务器发出请求

9 楼 kdekid 2007-05-09  

yfmine 写道

另外，想请问一下，对于新闻发布系统那种纯静态页面，apache有没有什么模块能判断静态页面是否存在，如果不存在，才给 应用服务器发出请求呢？

mod_rewrite 是可以的

10 楼 robbin 2007-05-09  

yfmine 写道

robbin讲的都是对象 缓存，想冒昧请问一下，javaeye使用了页面 缓存吗？对于页面 缓存，那么是算作粗粒度还是细粒度呢？这样做的也应该可以控制到比较高的 命中率吧，和对象 缓存相比，两者各有什么优劣，或者说两者一起使用是否能够做到比单纯的对象 缓存更好呢？

在我们做过的一个web项目中，是通过模版生成伪静态页面，说它是伪静态，是因为这个页面本身也是一个模版，在生成最终页面呈现给用户时，会填入一些动态的数据，就比如这个论坛的投票数量什么的。相当于磁盘 缓存了，但这个是 应用服务器的本地磁盘，速度上很快，而且避免了服务器之间的网络通信。比如论坛里每个帖子的文章内容，不需要再去数据库或者 缓存里取，这样是不是能减少与memcached通信的流量呢。

web 应用多数都是查询大于数据操作，那么cache用于解决性能是屡试不爽，但是对于插入，更新频繁的企业 应用，一般是应该从哪方面去解决的呢。

另外，想请教下对于新闻发布系统那种纯静态页面，apache有没有什么模块，可以判断静态页面是否存在，如果不存在，才给 应用服务器发出请求

http://robbin.iteye.com/blog/66582

11 楼 yfmine 2007-05-09  

kdekid 写道

yfmine 写道

另外，想请问一下，对于新闻发布系统那种纯静态页面，apache有没有什么模块能判断静态页面是否存在，如果不存在，才给 应用服务器发出请求呢？

mod_rewrite 是可以的

谢谢，刚才查了文档，RewriteCond -s可以...

Readonly 写道

另外，偶的小脑袋哪能记住几天前看到第几页这种OOXX的事情，还要记住谁在第几页的发言简直是@#￥%...这种大肠帖都是点开最后一页，然后依靠回复时间来找到大致位置

帖子太多,记不住,所以头就大了,所以就记住了......  

robbin 写道

http://robbin.iteye.com/blog/66582

谢谢robbin,跑题了,不好意思...

12 楼 ajoo 2007-05-09  

robbin 写道

真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。当然了，不管怎么说，通过使用对象 缓存，是毫无疑问可以大幅度降低数据库的负载压力的，有效提升web 应用的性能的。

关于这一点，我再给出一组数据来加深大家的印象，通过使用操作系统网络工具进行统计：

JavaEye网站web server的端口每秒数据流量是2MB；
JavaEye网站的MySQL数据库端口的每秒数据流量是1.2MB；
而网站的memcached的端口每秒的数据流量高达5MB。

robbin这个解释很清楚了。就是说对象 缓存最起作用的是数据库无能为力的地方。
这点我完全同意。

那么另外一个疑问：
全表扫描是相当相当可怕的。也许在几万条记录的表里面还无所谓，但是如果是上百万条的表，那么一个select要等上十秒二十秒不算什么新闻。
可是，不管 缓存如何，第一次总要query数据库的。那么用户在第一次的时候还是要经过漫长的等待的。这样似乎也不太理想。我总觉得遇到这种情况，最根本的解决方法是优化数据库，建索引也好，冗余也好，改变对象设计也好，总之目标是干掉全表扫描。而如果这么干了，那么回过头来，对象 缓存的作用就又被稀释了。

13 楼 robbin 2007-05-09  

ajoo 写道

robbin 写道

真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。当然了，不管怎么说，通过使用对象 缓存，是毫无疑问可以大幅度降低数据库的负载压力的，有效提升web 应用的性能的。

关于这一点，我再给出一组数据来加深大家的印象，通过使用操作系统网络工具进行统计：

JavaEye网站web server的端口每秒数据流量是2MB；
JavaEye网站的MySQL数据库端口的每秒数据流量是1.2MB；
而网站的memcached的端口每秒的数据流量高达5MB。

robbin这个解释很清楚了。就是说对象 缓存最起作用的是数据库无能为力的地方。
这点我完全同意。

那么另外一个疑问：
全表扫描是相当相当可怕的。也许在几万条记录的表里面还无所谓，但是如果是上百万条的表，那么一个select要等上十秒二十秒不算什么新闻。
可是，不管 缓存如何，第一次总要query数据库的。那么用户在第一次的时候还是要经过漫长的等待的。这样似乎也不太理想。我总觉得遇到这种情况，最根本的解决方法是优化数据库，建索引也好，冗余也好，改变对象设计也好，总之目标是干掉全表扫描。而如果这么干了，那么回过头来，对象 缓存的作用就又被稀释了。

全表的扫描不见得能够全部消除掉，很多时候还是不得不写全表扫描的SQL。

14 楼 downpour 2007-05-10  

全表扫描真的很难避免，尤其是项目一大，参与的人一多，基本上随便挑一挑就能找出全表扫描的SQL。

我感觉 缓存的容量是一个非常关键的数值，频繁的LRU几乎就是 缓存的杀手。不知道Robbin在调整这个参数的时候是如何判断分析的。

15 楼 cherami 2007-05-10  

显示分页并不会对性能或者 缓存造成太大的麻烦，最多是多了一个SQL而已，取一个总体的记录数，这个可以通过开发架构解决。

如果不提供就极大的限制了功能，不能因为技术而对功能进行限制！

16 楼 robbin 2007-05-10  

downpour 写道

全表扫描真的很难避免，尤其是项目一大，参与的人一多，基本上随便挑一挑就能找出全表扫描的SQL。

我感觉 缓存的容量是一个非常关键的数值，频繁的LRU几乎就是 缓存的杀手。不知道Robbin在调整这个参数的时候是如何判断分析的。

Java的 缓存一般是有接口来进行统计的，可以自己编程来监控 缓存的 命中率。例如confluence自己就在后台提供了 缓存命中率的统计监控数据。可以根据 命中率来调整 缓存大小。

如果是RoR去连接memcached，没有什么监控手段，那么我的办法也很直观，就是比较数据库的容量，如果数据库的数据容量达到了500MB，那么我就会给memcached开512MB的 缓存空间。

17 楼 chenqj 2007-05-10  

cherami 写道

显示分页并不会对性能或者 缓存造成太大的麻烦，最多是多了一个SQL而已，取一个总体的记录数，这个可以通过开发架构解决。

如果不提供就极大的限制了功能，不能因为技术而对功能进行限制！

如果是用sql的话，虽然只是多了一个sql，但如果一个列表页显示50个帖子的话，就是多了50个sql

18 楼 kabbesy 2007-05-10  

chenqj 写道

cherami 写道

显示分页并不会对性能或者 缓存造成太大的麻烦，最多是多了一个SQL而已，取一个总体的记录数，这个可以通过开发架构解决。

如果不提供就极大的限制了功能，不能因为技术而对功能进行限制！

如果是用sql的话，虽然只是多了一个sql，但如果一个列表页显示50个帖子的话，就是多了50个sql

对于论坛，大部分功能集中在list、byKey，count
其中count部分又属于易失性的，普通的对象 缓存是不适合的，当然50个count（*）就更不适合了

这个可以靠业务逻辑相关的内存计数器来解决

19 楼 cherami 2007-05-10  

chenqj 写道

如果是用sql的话，虽然只是多了一个sql，但如果一个列表页显示50个帖子的话，就是多了50个sql

晕，这个是什么逻辑啊，我说的多一个SQL是取全部匹配的记录数，用于计算总共的页数，而且这个SQL是共通的，就是在正常的记录查询上包一层

一个列表显示50个帖子，这个也是一个SQL而已，如果是用hibernate的 缓存机制的话，才可能是50次执行。

20 楼 cherami 2007-05-10  

kabbesy 写道

对于论坛，大部分功能集中在list、byKey，count
其中count部分又属于易失性的，普通的对象 缓存是不适合的，当然50个count（*）就更不适合了

这个可以靠业务逻辑相关的内存计数器来解决

用于分页的count不需要考虑易失性，大数据，频繁更新的数据，查询都是有一个短暂的有效性的，google也无法解决这个 问题。100％的精确对于大数据量而且频繁更新的系统而言是不可能的

21 楼 julyboxer 2007-05-10  

cherami 写道

kabbesy 写道

对于论坛，大部分功能集中在list、byKey，count
其中count部分又属于易失性的，普通的对象 缓存是不适合的，当然50个count（*）就更不适合了

这个可以靠业务逻辑相关的内存计数器来解决

用于分页的count不需要考虑易失性，大数据，频繁更新的数据，查询都是有一个短暂的有效性的，google也无法解决这个 问题。100％的精确对于大数据量而且频繁更新的系统而言是不可能的

嗯。确实没有好办法解决分页的count这个 问题以达到１００％精确，我想是不是用户请求第一个页面的时候才去查询的总记录数。中间页面的话，就不去查询总记录?

22 楼 叶子 2007-05-10  

搜索的话，分页结果差异比较大很难确定，可如果是主题列表，回帖列表，那么不是结果很稳定么。

23 楼 iunknown 2007-05-17  

downpour 写道

全表扫描真的很难避免，尤其是项目一大，参与的人一多，基本上随便挑一挑就能找出全表扫描的SQL。

我感觉 缓存的容量是一个非常关键的数值，频繁的LRU几乎就是 缓存的杀手。不知道Robbin在调整这个参数的时候是如何判断分析的。

memcached 有一个 stats 命令，可以查看到它自启动之后的一些统计值，里面有 命中次数（get_hits） 和 失败（get_misses） 次数。

查看文本 打印

1. bash-2.05a$ telnet 0 11211  
2. stats  
3. STAT rusage_user 0.770000  
4. STAT rusage_system 75.630000  
5. STAT curr_items 291984  
6. STAT total_items 500000  
7. STAT cmd_get 500000  
8. STAT cmd_set 500000  
9. STAT get_hits 291984  
10. STAT get_misses 208016  
11. END  

24 楼 lszone 2007-05-21  

robbin 写道

不过这里要提醒的一点，有将近一半的SQL都被 缓存，不意味着性能可以提升一倍。这是因为能够被 缓存的都是按照主键查询单条记录的SQL，这些SQL本身即使发送到数据库，对数据库造成的压力也没有想像的那么大。真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。

深有感触，索引如果没建好，简直就是灾难，其它的优化都是空谈