通过Redis的自增set实现“乐观锁”,从而控制并发

2020-11-20T09:51:00

[scode type="blue"]这还要从项目提出的静默签到开始讲起[/scode]

  • 学长说我们的新院统战要对用户的登录进行记录,也就是签到,但是不是用户手动去页面点击签到,而是用户今天登录了,或者说向服务器发送请求了,那么就算是签过到了,数据库有他今天的登录记录。
  • emmm,一开始还真是让我头大,因为不是新写一个接口去进行签到,而是通过请求进行签到,一天只能签一次,那么首先这个判断的位置只能是放在过滤器中,当用户请求进来时,拦截下来,拿token,获取用户id。
  • ok,拿到用户id了,但是不能去通过查数据库来检测用户是否这一天已经登陆过,因为慢,而且请求是时时刻刻都有的,查数据库显然不理想,那肯定就是去查redis里有没有今天的记录,把userId当作key,value随意,就有了一开始的写法:
//如果缓存里没有
if (!redisUtils.hasKey(key)) {
    //写入数据库 ...
    //写入缓存,第二天凌晨过期
    redisUtils.set(key, value, DateUtil.getTomorrowSeconds(new Date()));
}
  • 一开始这样写,还没有什么太大的问题,但是之后就发现了数据库第一时刻记录了多条用户登录记录,经过排查之后,可以初步判定是多条请求同时进来,而 if (!redisUtils.hasKey(key)) 需要时间并没有全部拦截,所以上面的写法是有问题的。
  • 那我就想了,既然redis读取有延时,我直接用 ConcurrentHashMap 来记录做外层第一次拦截,同时写一个定时任务清空,同时里面再加第二层判断拦截记录到redis(考虑到服务器重启),这样延迟足够小了吧,应该可以拦下并发的请求访问的,可结果告诉我还是不行,即使是用了map也拦截不全。

[scode type="blue"]通过redis的自增set做乐观锁[/scode]

  • 现在可以明确是要控制并发访问了,这一块我之前有写过悲观锁和乐观锁,但很明显这个不能使用悲观锁,太慢了。那就使用校验字段来加乐观锁,通过查阅知道redis是单线程的,所以在写入操作一定是线程安全的!那么就要使用到redis的自增set了:
    /**
     * 缓存自增放入(乐观锁)
     *
     * @param key   键
     * @param value 自增大小(Long)
     * @return 返回已增长度
     */
    public Long setnc(String key, Object value) {
        try {
            return redisTemplate.opsForValue().increment(key, (Long)value);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
            return 0L;
        }
    }
  • 这个可以保证每一次进入的请求都会增加该条缓存的增量记录值,由于redis是线程安全的,所以可以保证每个请求最后返回的自增长度是不同的,那么怎们就对第一次自增后的长度做一个判断:
       //如果自增长度小于等于1(只有第一次,后面的都会越来越大)
       if (redisUtils.setnc(key, 1L) <= 1L) {
            //存入数据库...
            //设置过期时间
            redisUtils.expire(SIGN_KEY + userId, DateUtil.getTomorrowSeconds(new Date()));
        }
  • 经过测试,可以控制redis的并发访问所带来的差错,这样,静默签到算是完成了。
当前页面是本站的「Baidu MIP」版。发表评论请点击:完整版 »