用观察者模式解决点击一次文章 update一次数据库的问题

我倒是认为用AOP的方式来解决比较好。

在Struts2下面的话用拦截器的方式解决。

只有当点击量达到一定值，才用拦截器更新数据库。貌似这样能彻底解耦。
不过楼上的兄弟说同步怎么办。似乎是个问题。

利用JSON微量数据通信

这确实是个问题  定时flush的话 貌似可行  但一次flush全部数据的话 短时间内可能把数据库压垮
分批处理的话需要有类似队列结构的Map，按照顺序flush

回楼上几位提议，这个问题偶们经历过，实践证明分布式cache是不靠谱的。

如果访问量上来了，用jboss cache这种传说中通讯量很小的cache，在千兆网络中也会造成网络堵塞，影响巨大，性能也差。

对于定时flush，间隔多大？如果间隔很短，其实就没有意义了，而且还可能增大系统负担。如果间隔很大，数据延迟以及内存占用都是问题。

对于这种场景，我觉得有这几个方式值得一试，不过我也没有验证过，呵呵。

1. 普通cache + 超时通知。 cache就是普通的cache，好比ehcache，设定记录最大存活时间（保证延迟可以接受）和最大允许的记录数（限制内存使用），当记录到达最大存活时间或者被挤出缓存时，截获此事件，将移出的记录数据同步到数据库中。这种方式应用比较简单，不过很多cache不支持事件功能比较麻烦。


2. 只cache热门帖子。可以按照业务性质或者点击规则，例如增加一个字段，用于计算帖子最近2分钟的点击次数，如果点击次数操作N次，就认定为热门帖子，对计数进行cache，其他的直接放过。计数增加时，先查看是否在cache中，如果在就更新cache数据，不在就更新数据库，并计算是否需要载入cache。cache中的数据可以定时flush，定时删除，也可以配合方式1进行。

3. 创建一个临时表，把更新信息写入到临时表中，在弄个后台线程慢慢算，慢慢更新。或者弄个单独的统计数据库存着，或是写文件日志。都一个道理。


4. 如果访问量不是非常庞大，好比网站日均pv过千万，直接数据update xxx a = a+ 1 ; 算了，性能还是可以接受的。至少mysql这方面就挺快的。也省事。

点击量是个典型的高频率读写系统，对缓存使用的常规策略一概无效，加上这个数据的价值不是很高（可靠性和事务性要求没有了），所以可以采用这样的方式：

延迟写；
每次写的时候直接从数据库同步到最新数据，使用增量方式；
拒绝分布式缓存（高失效性），拒绝单点缓存（访问频率太高，连接过多），只能够使用单机自己的缓存；

这种需求不需要同步cache的，就每个cache各管各写库。
超时功能没有的话，自己写一个好了，cache就是一个map，只做10次的这种个数cache，用专业的cache感觉还有点浪费呢。

一般都是这么做的 比较精辟

其实，这里面，数量更新的可靠性是最重要的一点。
如果中央式缓存可以在大访问量下，很稳定的接受数量count,那么每天凌晨做一次数据库的同步不是更好？

设置一个缓存的最大数，每当等于最大数量时，就进行批量更新，并清空缓存

同意其观点，用memcached做中央缓存,memcached有专门的方法来加1和减1，每隔一段时间把数据取出再更新数据库，并清零memcached相关项。