惊现支撑1亿pv/天的超级数据库解决方案
我说的系统主要是构建在hibernate之上的高效数据库缓存系统，其中包含了分布式解决方案，该系统已经应用在舍得网上了，没有发现大问题，
舍得网支撑1亿pv/天构架，开源了
说是支持1亿pv/天，也许有点夸张，也是为了吸引您能点进来，如果您能认真看完相信也不会让您失望，当然，肯定有很多“高手”会对此会嗤之以鼻，没关系，有很多眼高手低的人总喜欢评论别人却从不会看清自己。
如果大家真想支持我、支持中国人开源项目，请把该文贴到自己的博客中或者收藏本文，记得包含文档的下载地址！！！！！！！谢谢。
我说的系统主要是构建在hibernate之上的高效数据库缓存系统，其中包含了分布式解决方案，该系统已经应用在舍得网上了，没有发现大问题，本人也相信该系统已经足够强大，应付数百万IP/天的应用都不是问题，我这么说肯定有人会对此表示怀疑，其实系统到底能撑多少IP/天不在于系统本身而是在于使用该系统的人。
代码看上去很简单，其实却是两年经验的总结，整过过程也遇到了很多难点，最后一一解决了，所以也请各位珍惜他人的劳动成果。本系统非常简洁易用，主程序BaseManager.java不到1000行代码，用“精悍”来形容绝对不为过，1000行代码却包含了数据库对象的缓存、列表和长度的缓存、按字段散列缓存、update延时更新、自动清除列表缓存等功能，用它来实现像论坛、博客、校友录、交友社区等绝大部分应用网站都足够了。
我在理想状态下做了压力测试，在没有数据库操作的jsp页面(舍得网新首页)里可以完成2000多requests每秒（正常情况可能有1/1000的request有数据库查询，其余999/1000都是直接从缓存里读取），物品详情页每秒可完成3000多 requests，纯静态html页面也只能完成7000多requests/秒，我对首页进行了三个小时的压力测试，完成了24850800个 requests，java一点事都没有，内存没有上涨。按照2000个requests/秒算，一天按15小时计算，那么每天能完成 3600*15*2000=1亿零8百万requests，当然这是理想状态，实际状态就算打一折，还能完成1000万pv/天，要知道，这只是一个普通 1万3千块钱买的服务器，内存4G，CPU2个，LinuxAS4系统，apache2.0.63/resin2.1.17/jdk6.0的环境。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。现在进入正题。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
为什么要用缓存？如果问这个问题说明你还是新手，数据库吞吐量毕竟有限，每秒读写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，这样10万个帖子对应的所有回复列表都可以缓存起来，当有一个帖子有新的回复时，其余99999个帖子对应的回复列表都不会动，缓存的命中率极高。
第二种情况，就是后台需要显示最新的回复，sql语句应该是象
select id from T order by createTime desc limit 0,50
的样子，这种情况不需要散列，因为后台不可能有太多人访问，常用列表也不会太多，所以直接放到通用列表缓存B中即可。
第三种情况，获取一个用户的回复，sql语句象
select id from T where userId=2046 order by createTime desc limit 0,15
select id from T where userId=2046 order by createTime desc limit 15,15
select id from T where userId=2046 order by createTime desc limit 30,15
的样子，那么这种列表和第一种情况类似，用userId做散列即可。
第四种情况，获取一个用户对某个帖子的回复，sql语句象
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 0,15
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 15,15
的样子，这种情况比较少见，一般以topicId=2008为准，也放到key是topicId=2008这个散列Map里即可。
那么最后的缓存结构应该是下面这个样子：
缓存A是：
Key键（long型） Value值（类型T）
11 Id=11的T对象
22 Id=22的T对象
133 Id=133的T对象
……
列表缓存B是：
Key键（String型） Value值（ArrayList型）
from T order by createTime desc limit 0,50 ArrayList，对应取出来的所有id
from T order by createTime desc limit 50,50 ArrayList，对应取出来的所有id
from T order by createTime desc limit 100,50 ArrayList，对应取出来的所有id
……
散列缓存C是：
Key键（String型） Value值（HashMap）
userId=2046 Key键（String型） Value值（ArrayList）
userId=2046#0,5 id组成的List
userId=2046#5,5 id组成的List
userId=2046#15,5 id组成的List
……
userId=2047 Key键（String型） Value值（ArrayList）
userId=2047#0,5 id组成的List
userId=2047#5,5 id组成的List
userId=2047#15,5 id组成的List
……
userId=2048 Key键（String型） Value值（ArrayList）
userId=2048#topicId=2008#0,5 id组成的List
userId=2048#5,5 id组成的List
userId=2048#15,5 id组成的List
……
……
总结：这种缓存思路可以存储大规模的列表，缓存命中率极高，因此可以承受超大规模的应用，但是需要技术人员根据自身业务逻辑来配置需要做散列的字段，一般用一个表的索引键做散列（注意顺序，最散的字段放前面），假设以userId为例，可以存储N个用户的M种列表，如果某个用户的相关数据发生变化，其余N- 1个用户的列表缓存纹丝不动。以上说明的都是如何缓存列表，缓存长度和缓存列表思路完全一样，如缓存象select count(*) from T where topicId=2008这样的长度，也是放到topicId=2008这个散列Map中。如果再配合好使用mysql的内存表和memcached，加上F5设备做分布式负载均衡，该系统对付像1000万IP/天这种规模级的应用都足够了，除搜索引擎外一般的应用网站到不了这种规模。
再次申明：系统到底是不是强大不在系统本身而在于使用该系统的人！！！
这个缓存系统是我和同事几年经验的总结，看似简单，其实也没那么简单，把它作为开源有下面几个目的：第一，真的希望有很多人能用它；第二：希望更多的人能够完善和改进它；第三：希望大家能聚到一起为通用高效数据库缓存构架作出贡献，毕竟，数据库操作是各种应用最常用的操作，也是最容易产生性能瓶颈的地方。
Zip包中包含了配置方法和测试用的jsp，只要把它配置成一个web应用就可以快速调试并看到缓存的力量了，文档和下载地址是http://shedewang.com/akaladocs/api/com/akala/dbcache/core/BaseManager.html。
配置说明文件在docs/开始配置.txt里有说明。
最后啰嗦一句，如果大家真想支持我、支持中国人开源项目，请把该文贴到自己的博客中或者收藏本文，记得包含文档的下载地址！！！！！！！谢谢。thank you and Good luck。
QQ群：24561583
复制过来格式有点乱了，还是自己下载一个下来看看吧，里面有个word文档，写得比较清晰。
说是支持1亿pv/天，也许有点夸张，也是为了吸引您能点进来，如果您能认真看完相信也不会让您失望，当然，肯定有很多“高手”会对此会嗤之以鼻，没关系，有很多眼高手低的人总喜欢评论别人却从不会看清自己。
如果大家真想支持我、支持中国人开源项目，请把该文贴到自己的博客中或者收藏本文，记得包含文档的下载地址！！！！！！！谢谢。
我说的系统主要是构建在hibernate之上的高效数据库缓存系统，其中包含了分布式解决方案，该系统已经应用在舍得网上了，没有发现大问题，本人也相信该系统已经足够强大，应付数百万IP/天的应用都不是问题，我这么说肯定有人会对此表示怀疑，其实系统到底能撑多少IP/天不在于系统本身而是在于使用该系统的人。
代码看上去很简单，其实却是两年经验的总结，整过过程也遇到了很多难点，最后一一解决了，所以也请各位珍惜他人的劳动成果。本系统非常简洁易用，主程序BaseManager.java不到1000行代码，用“精悍”来形容绝对不为过，1000行代码却包含了数据库对象的缓存、列表和长度的缓存、按字段散列缓存、update延时更新、自动清除列表缓存等功能，用它来实现像论坛、博客、校友录、交友社区等绝大部分应用网站都足够了。
我在理想状态下做了压力测试，在没有数据库操作的jsp页面(舍得网新首页)里可以完成2000多requests每秒（正常情况可能有1/1000的request有数据库查询，其余999/1000都是直接从缓存里读取），物品详情页每秒可完成3000多 requests，纯静态html页面也只能完成7000多requests/秒，我对首页进行了三个小时的压力测试，完成了24850800个 requests，java一点事都没有，内存没有上涨。按照2000个requests/秒算，一天按15小时计算，那么每天能完成 3600*15*2000=1亿零8百万requests，当然这是理想状态，实际状态就算打一折，还能完成1000万pv/天，要知道，这只是一个普通 1万3千块钱买的服务器，内存4G，CPU2个，LinuxAS4系统，apache2.0.63/resin2.1.17/jdk6.0的环境。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。现在进入正题。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
为什么要用缓存？如果问这个问题说明你还是新手，数据库吞吐量毕竟有限，每秒读写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，这样10万个帖子对应的所有回复列表都可以缓存起来，当有一个帖子有新的回复时，其余99999个帖子对应的回复列表都不会动，缓存的命中率极高。
第二种情况，就是后台需要显示最新的回复，sql语句应该是象
select id from T order by createTime desc limit 0,50
的样子，这种情况不需要散列，因为后台不可能有太多人访问，常用列表也不会太多，所以直接放到通用列表缓存B中即可。
第三种情况，获取一个用户的回复，sql语句象
select id from T where userId=2046 order by createTime desc limit 0,15
select id from T where userId=2046 order by createTime desc limit 15,15
select id from T where userId=2046 order by createTime desc limit 30,15
的样子，那么这种列表和第一种情况类似，用userId做散列即可。
第四种情况，获取一个用户对某个帖子的回复，sql语句象
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 0,15
select id from T where topicId=2008 and userId=2046 order by createTime desc limit 15,15
的样子，这种情况比较少见，一般以topicId=2008为准，也放到key是topicId=2008这个散列Map里即可。
那么最后的缓存结构应该是下面这个样子：
缓存A是：
Key键（long型） Value值（类型T）
11 Id=11的T对象
22 Id=22的T对象
133 Id=133的T对象
……
列表缓存B是：
Key键（String型） Value值（ArrayList型）
from T order by createTime desc limit 0,50 ArrayList，对应取出来的所有id
from T order by createTime desc limit 50,50 ArrayList，对应取出来的所有id
from T order by createTime desc limit 100,50 ArrayList，对应取出来的所有id
……
散列缓存C是：
Key键（String型） Value值（HashMap）
userId=2046 Key键（String型） Value值（ArrayList）
userId=2046#0,5 id组成的List
userId=2046#5,5 id组成的List
userId=2046#15,5 id组成的List
……
userId=2047 Key键（String型） Value值（ArrayList）
userId=2047#0,5 id组成的List
userId=2047#5,5 id组成的List
userId=2047#15,5 id组成的List
……
userId=2048 Key键（String型） Value值（ArrayList）
userId=2048#topicId=2008#0,5 id组成的List
userId=2048#5,5 id组成的List
userId=2048#15,5 id组成的List
……
……
总结：这种缓存思路可以存储大规模的列表，缓存命中率极高，因此可以承受超大规模的应用，但是需要技术人员根据自身业务逻辑来配置需要做散列的字段，一般用一个表的索引键做散列（注意顺序，最散的字段放前面），假设以userId为例，可以存储N个用户的M种列表，如果某个用户的相关数据发生变化，其余N- 1个用户的列表缓存纹丝不动。以上说明的都是如何缓存列表，缓存长度和缓存列表思路完全一样，如缓存象select count(*) from T where topicId=2008这样的长度，也是放到topicId=2008这个散列Map中。如果再配合好使用mysql的内存表和memcached，加上F5设备做分布式负载均衡，该系统对付像1000万IP/天这种规模级的应用都足够了，除搜索引擎外一般的应用网站到不了这种规模。
再次申明：系统到底是不是强大不在系统本身而在于使用该系统的人！！！
这个缓存系统是我和同事几年经验的总结，看似简单，其实也没那么简单，把它作为开源有下面几个目的：第一，真的希望有很多人能用它；第二：希望更多的人能够完善和改进它；第三：希望大家能聚到一起为通用高效数据库缓存构架作出贡献，毕竟，数据库操作是各种应用最常用的操作，也是最容易产生性能瓶颈的地方。
Zip包中包含了配置方法和测试用的jsp，只要把它配置成一个web应用就可以快速调试并看到缓存的力量了，文档和下载地址是http://shedewang.com/akaladocs/api/com/akala/dbcache/core/BaseManager.html。
配置说明文件在docs/开始配置.txt里有说明。
最后啰嗦一句，如果大家真想支持我、支持中国人开源项目，请把该文贴到自己的博客中或者收藏本文，记得包含文档的下载地址！！！！！！！谢谢。thank you and Good luck。
QQ群：24561583
复制过来格式有点乱了，还是自己下载一个下来看看吧，里面有个word文档，写得比较清晰。
很赞哦！()
大图广告（830*140）
