哥特死亡工业 2015-10-03
Redis/Memcached高并发访问下的缓存失效时可能产生Dogpile效应(CacheStampede效应)
避免Memcached缓存的Dogpile效应
Memcached的read-throughcache流程:
Memcached缓存示例:
package com.chinaso.phl.high.current; import java.util.ArrayList; import java.util.List; import net.rubyeye.xmemcached.MemcachedClient; /** * 缓存一定加载业务层上 * @author piaohailin * @date 2013-12-10 */ public class TestService { private TestDao testDao = new TestDao(); MemcachedClient memcachedClient = null; public TestService(MemcachedClient memcachedClient) { this.memcachedClient = memcachedClient; } public List<TestVo> getAll() { List<TestVo> result = null; /*读取缓存 */ try { result = memcachedClient.get("all"); } catch (Exception e) { /* 如果发生异常,则处理掉, 继续读取持久化存储层 不能因为缓存的异常,而中断业务 */ } if (result != null) { return result; } /*读取持久层 */ result = testDao.getAll(); /*设置缓存*/ try { if (result == null) { //区分查不出数据和持久层里面是空数据的情况,防止高并发空查询持久层 //是一条空查询,超时时间可以设置短点 memcachedClient.set("all", 500, new ArrayList<TestVo>()); } else { //查询出数据,超时时间可以稍微多一些 memcachedClient.set("all", 1800, result); } } catch (Exception e) { } /*返回数据*/ return result; } }
假如上面的testDao.getAll()是耗时3秒(或更长时间)的运算或数据库操作.当缓存服务器不可用(比如:缓存实例宕机,或网络原因)或是缓存失效瞬间,如果恰好有大量的访问请求,那就会出现机器CPU消耗或数据库操作次数短时间内急剧攀升,可能会引发数据库/Web服务器故障.这种方式不适合在高并发场景下使用,适合并发量低,单次查询耗时的场景.
避免这样的Dogpile效应,通常有两种方法:
使用独立的更新进程
使用独立的进程(比如:cronjob)去更新缓存,而不是让web服务器即时更新数据缓存.举个例子:一个数据统计需要每五分钟更新一次(但是每次计算过程耗时1分钟),那么可以使用cronjob去计算这个数据,并更新缓存.这样的话,数据永远都会存在,即使不存在也不用担心产生dogpile效应,因为客户端没有更新缓存的操作.这种方法适合不需要即时运算的全局数据.但对用户对象,朋友列表,评论之类的就不太适用.
使用”锁”
除了使用独立的更新进程之外,我们也可以通过加”锁”,每次只允许一个客户端请求去更新缓存,以避免Dogpile效应.
处理过程大概是这样的:
Memcached使用”锁”的示例:.
package com.chinaso.phl.high.current; import java.util.ArrayList; import net.rubyeye.xmemcached.MemcachedClient; /** * @author piaohailin * @date 2013-12-10 */ public class TestSynchronizedService { private TestDao testDao = new TestDao(); MemcachedClient memcachedClient = null; public TestSynchronizedService(MemcachedClient memcachedClient) { this.memcachedClient = memcachedClient; } public TestVo get(String key) throws Exception { TestVo result = null; /*读取缓存 */ try { result = memcachedClient.get(key); } catch (Exception e) { /* 如果发生异常,则处理掉, 继续读取持久化存储层 不能因为缓存的异常,而中断业务 */ } if (result != null) { return result; } //此处用法参考类com.chinaso.phl.high.current.TestSychronizedString.java //只有在字符串内容相同的时候才会锁起来 synchronized (key.intern()) { try { //从缓存读取会比较慢,此处应该在本地设置一个flag,以提高速度 result = memcachedClient.get(key); } catch (Exception e) { } if (result == null) { /*读取持久层 */ result = testDao.get(key); /*设置缓存*/ try { if (result == null) { //区分查不出数据和持久层里面是空数据的情况,防止高并发空查询持久层 //是一条空查询,超时时间可以设置短点 memcachedClient.set(key, 500, new ArrayList<TestVo>()); } else { //查询出数据,超时时间可以稍微多一些 memcachedClient.set(key, 1800, result); } } catch (Exception e) { } } } /*返回数据*/ return result; } }
上面的处理方法有个缺陷,就是缓存失效时,所有请求都需要等待某个请求完成缓存更新,那样无疑会增加服务器的压力.如果能在数据失效之前的一段时间触发缓存更新,或者缓存失效时只返回相应状态让客户端根据返回状态自行处理,那样会相对比较好.
下面的get方法就是返回相应状态由客户端处理:
上面的memcached缓存失效时,只有一个客户端请求会返回Cache::GenerateData状态,其它的都会返回Cache::NotFound.客户端可通过检测这些状态做相应的处理.
需要注意的是:”锁”的TTL值应该大于generateData()消耗时间,但应该小于实际缓存对象的TTL值.
参考文章
文章中的Q2整说明的是“dogpile效应”
http://weibo.com/p/1001603862417250608209