本文由红薯在 开源中国-OSC源创会第58期【福州站】的演讲整理而成。
本文总字数:1516个
预计阅读时间:8分钟
嘉宾演讲视频地址:http://t.cn/RSlMZEX
嘉宾PPT下载地址:http://t.cn/RCIVAlD
开源中国的现状
我们现在全球排名是大概800名,每天的ip数超过80万,大概1000万的PV,超过5000万的动态请求。
开源中国有几个应用的策略,可能不仅仅是开源中国,我们整个做web网站的时候,缓存应用都有以下的几个场景。
对象缓存
对象缓存就是根据用户的编号,拿到用户的详细的资料。这个非常好理解。
列表缓存
比如我们今天发了什么新闻,会有一个列表的页面,这个列表存的是一个ID。假如要改一篇新闻,我们就可以根据ID获取它的渠道列表后再找到新闻详细的内容。这样只需要改一个对象缓存,清除那个对象缓存再更新一下就好了。
页面片段缓存
页面片段就好比首页有很多的内容,可以把某一块html保存到内存里,这样输出会很快。
在清除缓存的时候,我们的策略还有过期自动清除、程序清除和手工清除。
Ehcache缓存框架
开源中国是用Java开发的。Java在做缓存的时候有一个很著名的Ehcache框架,它是基于内存的一个缓存框架,速度非常快。因为不能把所有数据都放在内存里,它可以把一部分数据放进磁盘,是一个两级的缓存。它还支持多个区域的缓存结构,用户是一个缓存,新闻帖子之类的可以单独设置缓存失效策略。Ehcache还提供了缓存数据的侦听接口。一个缓存数据一旦出现问题,就会得到通知。Ehcache也支持集群部署。
J2Cache
开源中国成立公司是在2011年,网站在2008年就上线了。这个网站撑了有两三年的时间,后来数据长得很快,就开始出现问题了。第一个就是单节点无法应付高并发的访问。还有一个最可怕的问题就是因为程序更新很频繁,Java每次更新的时候都要重启。一旦重启后,整个Ehcache缓存里的数据都被清掉。所以说重启然后大量访问进来的话,数据库基本上很快就会崩掉了。
那么我们为什么不选择Ehcache的集群方案呢?因为当我们在一个节点里存数据的时候,它同时会通过网络传播的形式将数据复制到其它节点。这样会造成网络开销很大。而不用redis则是因为它读缓存数据非常慢。
我们想的方案是把Ehcache和redis结合起来,取长补短。尽量从本机取数据,取不到的时候再去redis里面取。
Ehcache+ redis,就是J2Cache。
这样结合可以保证高性能。数据基本上都是从Ehcache里面取的,有效的缓解应用冷启动对数据库的压力。应用和redis之间不会有大量的数据传输,因为大量数据传输只存在于冷启动的时候。
J2Cache数据读取流程
每次读数据的时候首先从Ehcache里先读,因为Ehcache在你的内存中。如果有的话直接返回,没有的话就通过通过网络去读redis的数据,如果数据有的话就把它塞到Ehcache里面,再返回。如果redis也没有,这时才读数据库的数据,然后同时把它的数据塞到Ehcache和redis里面,最后返回数据。
J2Cache数据更新流程
清除数据首先是要清除节点。其他节点在收到这个命令的时候,它会清除当前Ehcache里面对应的数据。这样的话清除某一个节点数据,然后通过广播把这数据给其他其他节点,同时也清楚这个数据,这样就保证了整个集群里面的缓存数据是同步的。
序列化库的选择
因为缓存数据要通过网络传输到redis上,所以我们要求所有的对象都必须是可序列化的。我们最终使用的是FST,因为它速度很快,生成的那个序列号体积也比较小,关键是它对你的项目没有任何侵入性。
我今天要分享的就这些,谢谢!
编者:IT大咖说,欢迎关注“itdakashuo”,@IT大咖说 ,转载请标明版权和出处。