本文由红薯在 开源中国-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大咖说 ，转载请标明版权和出处。