帖子 博客等资源点击量缓存杀手级解决方案
标题党了 
关于点击量几年前发过帖子http://www.iteye.com/topic/171240
现在看来太简单了 而且问题多多
最近有琢磨出了一套新的方案
进入正题
关于帖子点击量，通常的办法是缓存在内存，然后等到合适的时机写入数据库，一般是设置一个阈值，到达后更新数据库
这种方式主要面临如下几个问题：
1 有些帖子永远到达不了阈值怎么办？如阈值为10，但到9后再也没有人点击了
2 阈值设置多大合适？太大了服务器当机会丢失大量数据，太小了没啥意义
3 每个帖子到达阈值后都要访问数据库，能不能合并起来 只访问一次DB
采用阈值方式是被动的，应该用主动的方式来解决问题
主动方式的思路如下：cache ---》 文件 ---》DB
1 cache中保存两个点击量，我们称之为todayHits和yestodayHits
todayHits保存资源当天的点击量
yestodayHits保存昨天的点击量
2 定时把cache中发生变化的数据导出到文件，未发生变化的删除
3 把导出的文件导入到数据库。多数DB都提供命令. mysql 为 load data local infile
此方法是把文件中的数据追加到表尾，这样会导致一个资源对应多个点击量的问题，我们用导入时间获取最新的点击量
4 删除过期数据。每次追加后会使原来部分数据变得无意义，需要清理掉
主动方式会定时扫描cache中数据
空说太抽象 直接上代码
不重要的方法省略
设计Cahce的key和value
HitKey 封装了资源id和资源类型
最后为清理过期的无效数据，此过程可另找时间清理 不必与上述步骤同步进行
该缓存方案已初步完成，随着项目的变化也会做相应调整
到底性能如何 能否应付海量数据 还有待检验
2009-09-20 补充
最后一步清理过期数据 采用了新的方法
使用
我的测试结果是相差６倍左右．（myisam 和 innodb 都是这样）
不管是向空表中插还是向非空表中插入随即数据结果差不多都是这个数．
我是在一个虚拟机上测的．．．．． 也许不太靠谱．．．．．．
感谢 icefishc
我刚才又换了台机器测试了一下
表结构 innodb 无主键
能不能写一个学习一下
jms确实可以降低服务器的瞬间压力，实际上却没有节省资源
我的方案更强调的是节省资源
你的提法确实可以节省资源，但是你可以保证你的机器不崩溃吗？ 如果系统死了，你前面9次修改的东西都丢失了，你的用户是否可以接受呢？
说的没错 这也是我一直担心的问题，要解决这个问题就扯出缓存事务了 那问题就搞复杂了
另外 像点击量这种不是特别重要的数据有点偏差也是可以的
我们做程序的讲究的是思想的严密性，像你说的不是特别重要的数据有点偏差也是可以的。这种想法是绝对不能存在的。假设我们将你的方案移植到银行或者金融类的程序开发中，不是特别危险了？什么是程序设计？一个好的程序至少应该在设计上是严密的，而不是以一种侥幸的心理以阿Q式方式去安慰自己，这种情况是很少存在的。做程序员千万要杜绝这种思想的出现。
jms确实可以降低服务器的瞬间压力，实际上却没有节省资源
我的方案更强调的是节省资源
你的提法确实可以节省资源，但是你可以保证你的机器不崩溃吗？ 如果系统死了，你前面9次修改的东西都丢失了，你的用户是否可以接受呢？
说的没错 这也是我一直担心的问题，要解决这个问题就扯出缓存事务了 那问题就搞复杂了
另外 像点击量这种不是特别重要的数据有点偏差也是可以的
我们做程序的讲究的是思想的严密性，像你说的不是特别重要的数据有点偏差也是可以的。这种想法是绝对不能存在的。假设我们将你的方案移植到银行或者金融类的程序开发中，不是特别危险了？什么是程序设计？一个好的程序至少应该在设计上是严密的，而不是以一种侥幸的心理以阿Q式方式去安慰自己，这种情况是很少存在的。做程序员千万要杜绝这种思想的出现。
你说的太教条主义了,没错做程序员的要讲究的是思想的严密性,但是要结合需求来考虑,从需求来说,有的要求不能有任何误差,比如银行,但是显然lz的这种需求就是不要求绝对正确的,往往有很多业务,从技术上就是无法做到绝对准确的,所以你说的一大堆未免教条主义了 46 楼 C_J 2009-08-12 我晕了，有那么复杂吗？？
把几千条insert放在一个transaction，1次commit不就完事了么？
