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

[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的并发访问所带来的差错，这样，静默签到算是完成了。