针对增量请求的缓存机制实现

背景:

在web应用中,我们经常使用黑白名单,在http://blog.csdn.net/troy__/article/details/39320699中我们实现了一个线程安全的针对全量请求的缓存机制,这种技术主要是用于黑白名单的全量更新。但是我们不能经常请求全量吧,网络和数据库都会累死,所以在此我们设计实现一个针对增量请求的缓存机制。全量请求提供黑白名单低频度的更新,增量请求提供黑白名单高频度的更新。当然,全量和增量的应用场景也并不只是黑白名单。

设计概述:

使用缓存的关键之一是:缓存并不能保证实时性,但它提供的是曾经出现过的某个正确状态。(csdn大量使用缓存,且失效时长过长,导致博客专区中很多操作执行后很久都得不到页面上的更新。)

在对实时性要求、缓存效果、实现难度、业务场景这四点的权衡和折中后,我选择了增量的缓存粒度为1分钟。意思就是说对每个1分钟内的增量进行缓存的存储。

设计要点:

  1. 增量请求并不是只对增加的数据进行更新,还要对以前删除的数据进行更新。所以应该返回两个List,一个是新添加数据的List,一个是已删除数据的List。
  2. 在实际工作中,在数据库层面,对于新增加数据和删除数据有两种常见的处理方式:
    • 在一张表里进行操作:利用某个字段标记这条数据当前是否有效,例如当删除这条数据,把这个字段设为99,而新增一条数据,此字段为值1。在这种方式下,对于新增加数据和新删除数据只能通过modefie_time来搜索,而非create_time。
    • 在两张表里进行操作:用一张表储存现有数据,一张表储存已删除数据。这样检索新增加数据和新删除数据分别在两张表中进行。我们可以通过create_time检索。
  3. 缓存的粒度为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 + "]";
    }
}
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{
               return userManager.getIncrementUserIds(timeStamp);
          } 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>
public interface UserManager{
     /**用户拥有在timeStamp之前的正确数据*/
     public IncrementDO<Long> getIncrementUserIds(long timeStamp)
          throws ManagerException;
}
public class UserManagerImpl implement UserManager {
     UserDAO userDAO;LocalCache localCache;
          /**用户拥有在timeStamp之前的正确数据*/
     public IncrementDO<Long> getIncrementUserIds(long timeStamp)
          throws ManagerException {
          long ts = this.userDAO.getDBTimestamp(); // db 当前时间戳

          Calendar reqTime = Calendar.getInstance();         // 请求时间
          reqTime.setTime(new Date(timestamp));
          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(ts));
          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 ManagerException("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 = this.getSignalMinitIncreamentUserIds(
                        reqTime.getTimeInMillis(), reqTime.getTimeInMillis() + 60000);
        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 result;
     }
     private IncrementDO<Long> getSignalMinitIncreamentUserIds(
         long beginTimestamp, long endTimestamp) throws DAOException {
           IncrementDO<Long> result = (IncrementDO<Long>)
                localCache.get(Namespace.INC_USERIDS+"_"
                +beginTimestamp + "_" + endTimestamp);
           if (result == null) {
                 List<Long> addList = this.userDAO.getAddedUserIds(
                      beginTimestamp, endTimestamp);
                 List<Long> deletedList = this.userDAO.getDeletedUserIds(
                      beginTimestamp, endTimestamp);
                 result = new IncrementDO<Long>(deletedList, addList, endTimestamp);
                 localCache.put(Namespace.INC_USERIDS+"_"
                      +beginTimestamp + "_" + endTimestamp, result);
           }
           return result;
     }
}
时间: 2024-10-14 23:27:32

针对增量请求的缓存机制实现的相关文章

针对增量请求的缓存机制实现 - AOP

背景: 在web应用中,我们经常使用黑白名单,在http://blog.csdn.net/troy__/article/details/39320699中我们实现了一个线程安全的针对全量请求的缓存机制,这种技术主要是用于黑白名单的全量更新.但是我们不能经常请求全量吧,网络和数据库都会累死,所以在此我们设计实现一个针对增量请求的缓存机制.全量请求提供黑白名单低频度的更新,增量请求提供黑白名单高频度的更新.当然,全量和增量的应用场景也并不只是黑白名单. 设计概述: 使用缓存的关键之一是:缓存并不能保

Android三级缓存机制工具类的实现

一.三级缓存概述 (一)三级缓存的三级 第一级是内存,最快,不需要网络 第二级是本地,不需要网络 第三级是网络,需要网络请求 三级缓存机制的思想: 如果在内存中获取到数据,就不去本地和网络中获取. 如果在本地中获取到数据就不去网络中获取, 如果内存和本地中不存在数据,就要去网络中请求数据 三级缓存技术能有效节省用户的流量,但是也会增加一些内存负担. 二.使用示例展示三级缓存工具栏类的使用 程序运行后的页面: 虽然只用一个按钮和一个图片显示,但是通过测试(联网状态和断网状态对比)能知道图片是从网络

contenttype组件、Django缓存机制以及跨域请求

1 昨日回顾 版本控制 *** (1)url=127.0.0.1/course/?version=v100000 1 versioning_class=QueryParameterVersioning 'VERSION_PARAM':'version', 'DEFAULT_VERSION':'v2', 'ALLOWED_VERSIONS':['v1','v2'] 2 配置成全局:在setting里:QueryParameterVersioning (2)重要(以后建议用这种):127.0.0.1

IE 针对ajax get请求的缓存问题

在chrome,ff中发送ajax请求get内容时没有缓存的现象,但是在IE中会对请求进行缓存,从而导致更新的内容没有改变的问题. 如果,你把CPU的阈值设置为25了,前面页面也提示设置成功了,但是CPU的阈值却还是原来的50.调试时,会发现返回的值确实是原来的值50而不是你最新设置的值25.你换到chrome浏览器却没有这种现象. 结论: IE浏览器对ajax请求进行了缓存. 解决办法: 方法1: url地址后添加随机后缀进行url欺骗 xmlhttp.open("GET",&quo

手把手教你构建 Android WebView 的缓存机制 &amp; 资源预加载方案

前言 由于H5具备 开发周期短.灵活性好 的特点,所以现在 Android App大多嵌入了 Android Webview 组件进行 Hybrid 开发 但我知道你一定在烦恼 Android Webview 的性能问题,特别突出的是:加载速度慢 & 消耗流量 今天,我将针对 Android Webview 的性能问题,提出一些有效解决方案. 目录 1. Android WebView 存在什么性能问题? Android WebView 里 H5 页面加载速度慢 耗费流量 下面会详细介绍. 1.

Varnish缓存机制详细介绍及简单配置

Varnish是一款高性能的开源HTTP加速器,其主要用来做为反向代理中的缓存服务器使用,但其实Varnish本身也是具有反向代理功能的,但在创建连接和维持连接上,与Nginx相比差距很大,现在有一个很流行的架构就是前端用Nginx作为反向代理,后面加Varnish缓存服务器为Web服务加速 在将Varnish前先谈谈我们的浏览器缓存机制,现在的浏览器基本都具有缓存功能,它能将我们以前访问过的静态内容和可进行缓存的动态内容缓存再本地,而后在下次访问相同资源时,如果可以确认Server端的资源未发

9大浏览器端缓存机制分析

浏览器缓存(Browser Caching)是浏览器端保存数据用于快速读取或避免重复资源请求的优化机制,有效的缓存使用可以避免重复的网络请求和浏览器快速地读取本地数据,整体上加速网页展示给用户.浏览器端缓存的机制种类较多,总体归纳为九种,这里详细分析下这九种缓存机制的原理和使用场景.打开浏览器的调试模式->resources左侧就有浏览器的8种缓存机制. 一.http缓存 http缓存是基于HTTP协议的浏览器文件级缓存机制.即针对文件的重复请求情况下,浏览器可以根据协议头判断从服务器端请求文件

浏览器缓存机制详解

对于浏览器缓存,相信很多开发者对它真的是又爱又恨.一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了"错误"的东西,而在开发过程中千方百计地想把缓存禁掉.那么浏览器缓存究竟是个什么样的神奇玩意呢? 什么是浏览器缓存: 简单来说,浏览器缓存就是把一个已经请求过的Web资源(如html页面,图片,js,数据等)拷贝一份副本储存在浏览器中.缓存会根据进来的请求保存输出内容的副本.当下一个请求来到的时候,如果是相同的URL,缓存会根据缓存机制决定是直接使用副本响应访问请求,还是

Java缓存学习之二:浏览器缓存机制

浏览器端的九种缓存机制介绍 浏览器缓存是浏览器端保存数据用于快速读取或避免重复资源请求的优化机制,有效的缓存使用可以避免重复的网络请求和浏览器快速地读取本地数据,整体上加速网页展示给用户.浏览器端缓存的机制种类较多,总体归纳为九种,这里详细分析下这九种缓存机制的原理和使用场景.打开浏览器的调试模式->resources左侧就有浏览器的8种缓存机制. 一.http缓存 http缓存是基于HTTP协议的浏览器文件级缓存机制.即针对文件的重复请求情况下,浏览器可以根据协议头判断从服务器端请求文件还是从