memcached（二十）Dogpile效应
Redis/Memcached高并发访问下的缓存失效时可能产生Dogpile效应(CacheStampede效应)
避免Memcached缓存的Dogpile效应
Memcached的read-throughcache流程:
- A客户端读取缓存
- B没有的话就由客户查询持久层
- C生成缓存
- D返回数据
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效应.
处理过程大概是这样的:
- A请求的缓存没命中
- A请求”锁住”缓存key
- B请求的缓存没命中
- B请求需要等待直到”锁”释放
- A请求完成,并且释放”锁”
- B请求缓存命中(由于A的运算)
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