Java数据库缓存-思路.doc

Java数据库缓存思路 为什么要用缓存？如果问这个问题说明你还是新手，数据库吞吐量毕竟有限，每秒读写5000次了不起了，如果不用缓存，假设一个页面有100个数据库操作，50个用户并发数据库就歇菜，这样最多能支撑的pv也就50*3600*15=270万，而且数据库服务器累得半死，搞不好什么时候就累死了。我的这套缓存系统比单独用memcached做缓存还要强大，相当于在memcached上再做了两级缓存，大家都知道memcached很强了，但是吞吐量还是有限，每秒20000次get和put当遇到超大规模的应用时还是会歇菜，本地HashMap每秒可执行上百万次put和get，在这上面损耗的性能几乎可以忽略不记了。温馨提示：能不用分布式的时候就不要用分布式，非用分布式的时候再考虑用memcached，我的缓存系统在这方面都已经实现了，改个配置就可以了，有兴趣的可以仔细测试测试！ 一般数据库缓存在我看来包含四种。第一种：单个对象的缓存（一个对象就是数据库一行记录），对于单个对象的缓存，用HashMap就可以了，稍微复杂一点用LRU算法包装一个HashMap，再复杂一点的分布式用memcached即可，没什么太难的；第二种：列表缓存，就像论坛里帖子的列表；第三种：长度的缓存，比如一个论坛板块里有多少个帖子，这样才方便实现分页。第四种：复杂一点的group，sum，count查询，比如一个论坛里按点击数排名的最HOT的帖子列表。第一种比较好实现，后面三种比较困难，似乎没有通用的解决办法，我暂时以列表缓存（第二种）为例分析。 mysql和hibernate的底层在做通用的列表缓存时都是根据查询条件把列表结果缓存起来，但是只要该表的记录有任何变化（增加/删除/修改），列表缓存要全部清除，这样只要一个表的记录经常变化（通常情况都会这样），列表缓存几乎失效，命中率太低了。 本人想了一个办法改善了列表缓存，当表的记录有改变时，遍历所有列表缓存，只有那些被影响到的列表缓存才会被删除，而不是直接清除所有列表缓存，比如在一个论坛版（id=1）里增加了一个帖子，那么只要清除id=1这个版对应的列表缓存就可以了，版id=2就不用清除了。这样处理有个好处，可以缓存各种查询条件（如等于、大于、不等于、小于）的列表缓存，但也有个潜在的性能问题，由于需要遍历，CPU符合比较大，如果列表缓存最大长度设置成10000，两个4核的CPU每秒也只能遍历完300多次，这样如果每秒有超过300个insert/update/delete，系统就吃不消了。 在前面两种解决办法都不完美的情况下，本人和同事经过几个星期的思索，总算得出了根据表的某几个字段做散列的缓存办法，这种办法无需大规模遍历，所以CPU符合非常小，由于这种列表缓存按照字段做了散列，所以命中率极高。思路如下：每个表有3个缓存Map（key=value键值对），第一个Map是对象缓存A，在A中，key是数据库的id，Value是数据库对象（也就是一行数据）；第二个Map是通用列表缓存B，B的最大长度一般1000左右，在B中，key是查询条件拼出来的String（如start=0,length=15#active=0#state=0），Value是该条件查询下的所有id组成的List；第三个Map是散列缓存C，在C中，key是散列的字段（如根据userId散列的话，其中某个key就是userId=109这样的String）组成的String，value是一个和B类似的HashMap。其中只有B这个Map是需要遍历的，不知道说明白了没有，看完小面这个例子应该就明白了，就用论坛的回复表作说明，假设回复表T中假设有字段id，topicId，postUserId等字段（topicId就是帖子的id，postUserId是发布者id）。 第一种情况，也是最常用的情况，就是获取一个帖子对应的回复，sql语句应该是象 select id from T where topicId=2008 order by createTime desc limit 0,5 select id from T where topicId=2008 order by createTime desc limit 5,5 select id from T where topicId=2008 order by createTime desc limit 10,5 的样子，那么这种列表很显然用topicId做散列是最好的，把上面三个列表缓存（可以是N个）都散列到key是topicId=2008这一个Map中，当id是2008的帖子有新的回复时，系统自动把key是topicId=2008的散列Map清除即可。由于这种散列不需要遍历，因此可以设置成很大，例如100000