首页 > 代码库 > 针对增量请求的缓存机制实现 - AOP
针对增量请求的缓存机制实现 - AOP
背景：
在web应用中，我们经常使用黑白名单，在http://blog.csdn.net/troy__/article/details/39320699中我们实现了一个线程安全的针对全量请求的缓存机制，这种技术主要是用于黑白名单的全量更新。但是我们不能经常请求全量吧，网络和数据库都会累死，所以在此我们设计实现一个针对增量请求的缓存机制。全量请求提供黑白名单低频度的更新，增量请求提供黑白名单高频度的更新。当然，全量和增量的应用场景也并不只是黑白名单。设计概述：
使用缓存的关键之一是：缓存并不能保证实时性，但它提供的是曾经出现过的某个正确状态。(csdn大量使用缓存，且失效时长过长，导致博客专区中很多操作执行后很久都得不到页面上的更新。)
在对实时性要求、缓存效果、实现难度、业务场景这四点的权衡和折中后，我选择了增量的缓存粒度为1分钟。意思就是说对每个1分钟内的增量进行缓存的存储。
除此之外，我们使用了AOP技术进行代码的复用，以及对业务代码的解耦，并且使用Annotation技术对增量方法进行标记。
详细设计：
- 增量请求并不是只对增加的数据进行更新，还要对以前删除的数据进行更新。所以应该返回两个List，一个是新添加数据的List，一个是已删除数据的List。
- 在实际工作中，在数据库层面，对于新增加数据和删除数据有两种常见的处理方式：
- 在一张表里进行操作：利用某个字段标记这条数据当前是否有效，例如当删除这条数据，把这个字段设为99，而新增一条数据，此字段为值1。在这种方式下，对于新增加数据和新删除数据只能通过modefie_time来搜索，而非create_time。
- 在两张表里进行操作：用一张表储存现有数据，一张表储存已删除数据。这样检索新增加数据和新删除数据分别在两张表中进行。我们可以通过create_time检索。
- 缓存的粒度为1分钟，我们每次访问数据库的时间范围也是这一分钟，在这次访问中数据库返回的关于新添加数据的List与已删除数据的List不会出现数据重叠。但是在前一分钟的List和后一分钟的List之间可能出现数据重叠，如前一分钟添加的数据，下一分钟可能就被删除掉了，或者前一分钟添加的数据，这一分钟又被恢复了。所以我们在从缓存取出每一分钟的数据后，需要对数据进行整合操作。
额外考虑：
用不用多线程的锁来防止在缓存不命中的情况下，多个线程并发去获取数据库中的数据？用锁后，只需要一个线程去访问数据，其他线程等待并返回即可。
答： 在全量请求的情境下，上面的方案是不错的选择。原因有二，一是单次对数据库数据请求量太大，如果并发访问，数据库压力太大。二是，缓存数据失效时长较短，因为数据源中数据不断增删，会侧面增加并发的程度。而对于增量请求来说，上面两个问题都不存在，每一分钟的增删情况是固定的，不会随着时间推移而改变，所以缓存失效时长取决于缓存自身条件。所以我这里没有使用锁的方式。
范例实现：
/**增量包装类*/
public class IncrementDO<T> implements Serializable {
private static final long serialVersionUID = -6615881328594646517L;
/** 删除数据列表 **/
private final List<T> deletedList;
/** 增加数据列表 **/
private final List<T> addedList;
/** 时间戳 **/
private final Long timestamp;
public IncrementDO(List<T> deletedList, List<T> addedList, Long timestamp) {
super();
this.deletedList = deletedList;
this.addedList = addedList;
this.timestamp = timestamp;
}
public List<T> getDeletedList() {
return deletedList;
}
public List<T> getAddedList() {
return addedList;
}
public Long getTimestamp() {
return timestamp;
}
@Override
public String toString() {
return "IncrementDO[deletedList=" + deletedList.size() + ", addedList=" +
addedList.size() + ", timestamp=" + timestamp + "]";
}
}/**Annotation*/
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface LocalIncreaCacheOperation {
}public interface ConfigService {
/**用户拥有在timeStamp之前的正确数据，用户将调用这个接口*/
public IncrementDO<Long> getIncrementUserIds(long timeStamp)
throws ServiceException;
}
public class ConfigServiceImpl implements ConfigService {
UserManager userManager;
public IncrementDO<Long> getIncrementUserIds(long timeStamp)
throws ServiceException{
if(timeStamp < 0) {
throw new ServiceException("timestamp is wrong");
}
try{
long ts = this.userManager.getDBTimestamp(); // db 当前时间戳
return this.getIncrementUserIds(timeStamp,ts);
} catch (ManagerException e) {
throw new ServiceException(e);
}
}
/**
* 增量缓存的辅助接口，AOP将拦截这个接口
*/
@LocalIncreaCacheOperation
public IncrementDO<Long> getIncrementUserIds(long beginTimesStamp,
Long endTimesStamp) throws ServiceException{
try{
IncrementDO<Long> result = null;
List<Long> addList = this.userManager.getAddedUserIds(
beginTimesStamp, endTimesStamp);
List<Long> deletedList = this.userManager.getDeletedUserIds(
beginTimesStamp, endTimesStamp);
result = new IncrementDO<Long>(deletedList, addList, endTimesStamp);
return result;
}catch(ManagerException e) {
throw new ServiceException(e);
}
}
}/**ibatis sql，用STATUS=1表示数据有效，STATUS=99表示数据已删除*/
<select id="getAddedUserIds" resultClass="java.lang.Long"
parameterClass="java.util.Map">
<![CDATA[
SELECT USER_ID
FROM user
WHERE GMT_MODIFIED >= #begin# and
GMT_MODIFIED <= #end# and STATUS = 1
]]>
</select>
<select id="getDeletededUserIds" resultClass="java.lang.Long"
parameterClass="java.util.Map">
.....
</select>/**
* 核心切面实现
*/
@Aspect
public class LocalIncreaCacheAspect {
private LocalCache localCache;
@Around("execution(@LocalIncreaCacheOperation * *(..))")
public Object doCache(ProceedingJoinPoint pjpParam) throws Throwable {
final ProceedingJoinPoint pjp = pjpParam;
Signature sig = pjp.getSignature();
if (sig instanceof MethodSignature) {
MethodSignature mSig = (MethodSignature) sig;
String localCacheKey = mSig.getName();
Long beginTimesStamp = (Long) pjp.getArgs()[0];
Long endTimesStamp = (Long) pjp.getArgs()[1];
Calendar reqTime = Calendar.getInstance(); // 请求时间
reqTime.setTime(new Date(beginTimesStamp));
reqTime.set(reqTime.get(Calendar.YEAR),
reqTime.get(Calendar.MONTH),
reqTime.get(Calendar.DAY_OF_MONTH),
reqTime.get(Calendar.HOUR_OF_DAY),
reqTime.get(Calendar.MINUTE), 0); // 秒清零
Calendar curTime = Calendar.getInstance(); // db当前时间
curTime.setTime(new Date(endTimesStamp));
curTime.set(curTime.get(Calendar.YEAR),
curTime.get(Calendar.MONTH),
curTime.get(Calendar.DAY_OF_MONTH),
curTime.get(Calendar.HOUR_OF_DAY),
curTime.get(Calendar.MINUTE), 0); // 秒清零
long diffTime = curTime.getTimeInMillis()
- reqTime.getTimeInMillis();
if (diffTime < 0) {
throw new ServiceException("timestamp is wrong");
}
IncrementDO<Long> tmp;
Set<Long> add = new HashSet<Long>();
Set<Long> del = new HashSet<Long>();
long minCount = diffTime / (60 * 1000); // 相差分钟数
for (long i = 0; i < minCount; i++) { // 遍历相差的分钟数
tmp = null;
tmp = (IncrementDO<Long>) localCache.get(localCacheKey + "_"
+ reqTime.getTimeInMillis() + "_"
+ (reqTime.getTimeInMillis() + 60000));
if (tmp == null) {
tmp = (IncrementDO<Long>) pjp.proceed(new Object[] {
reqTime.getTimeInMillis(),
reqTime.getTimeInMillis() + 60000 });
localCache.put(localCacheKey + "_"
+ reqTime.getTimeInMillis() + "_"
+ (reqTime.getTimeInMillis() + 60000), tmp);
}
if (tmp != null) {
del.removeAll(tmp.getAddedList());
add.addAll(tmp.getAddedList());
add.removeAll(tmp.getDeletedList());
del.addAll(tmp.getDeletedList());
}
reqTime.add(Calendar.MINUTE, 1);
}
IncrementDO<Long> result = new IncrementDO<Long>(
new ArrayList<Long>(del), new ArrayList<Long>(add),
curTime.getTimeInMillis());
}
return pjp.proceed(pjp.getArgs());
}
}针对增量请求的缓存机制实现 - AOP
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。