Redis教程

分布式环境下redis自增值&定时失效

本文主要是介绍分布式环境下redis自增值&定时失效,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

需求&业务场景

  没有需求或者业务场景,去谈技术就是空中楼阁~

前置条件

● 分布式部署
● 多实例

业务需求

● 不同业务,有该业务标识且自增的单号。
● 单号规则 业务标识+日期+4位自增数字
● 4位自增数字是表示当天的,凌晨清零

构思

   因为有多个实例,所以在操作自增数字的时候需要用到分布式锁,同时需要当天凌晨清零,很容易想到redis,缓存一个key值,失效时间是到凌晨。同时,redis提供原子操作的自增指令。至于分布式锁,考虑用reddsion的红锁。
另外一个需要考虑的点就是凌晨失效的那个点的那一刻,并发问题。
● reddsion的红锁解决分布式,多个实例操作问题
● 给key设置一个到凌晨的失效时间
● 考虑凌晨失效时候的并发问题
● 保证自增的原子操作

实现

获取到第二天凌晨的毫秒数

 public Long getNowToNextDayMilliseconds() {
        //获取当前时间
        Calendar calendar = Calendar.getInstance();
        //当前天+1
        calendar.add(Calendar.DAY_OF_YEAR, 1);
        //将时分秒毫秒都设为0
        calendar.set(Calendar.HOUR_OF_DAY, 0);
        calendar.set(Calendar.SECOND, 0);
        calendar.set(Calendar.MINUTE, 0);
        calendar.set(Calendar.MILLISECOND, 0);
        //减去当前时间获取插值
        return (calendar.getTimeInMillis() - System.currentTimeMillis());
    }

格式化字符串

  最终的输出格式是type+YYYYMMDD+4位自增数字

private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd");
    private String getCode(String type, String number) {
        String date = sdf.format(new Date());
        StringBuffer buffer = new StringBuffer();
        buffer.append(type)
              .append(date);
        for (int i = number.length(); i < 4; i++) {
            buffer.append("0");
        }
        buffer.append(number);
        return buffer.toString();
    }

核心逻辑

  public String getOrderCode(String key) {
        Object value = redisTemplate.opsForValue().get(key);
        //如果值存在,直接自增返回        @第一个if   
        if (null != value) {
            return getCode(key, redisTemplate.opsForValue().increment(key).toString());
        }
        //拿不到值,说明可能到了零点,自增值失效,需要重新set 一个0进去
        //需要考虑分布式和本地并发问题,分布式通过redssion lock解决
        //本地并发可以通过lock 和 tryLock两种方案,lock是把while(true)放里面,本方案采用tryLock
        //while(true)里面两个分支,第一个分支是拿到锁,进去后需要考虑,执行成功后,临界区的线程进来所以需要先判空
        //第二个分支是拿不到锁,判断一下是否已经被拿到锁的线程set值成功,如果成功,直接返回
        RLock lock = redissonClient.getLock(CommonConstant.ORDER_CODE_LOCK_KEY + key);
        try {
            while (true) {
                //拿到锁就初始化值和失效时间,没拿到锁就继续获取key的值  
                if (lock.tryLock(CommonConstant.INTEGER_FIVE, TimeUnit.MICROSECONDS)) { // @第二个if  
                    if (null == redisTemplate.opsForValue().get(key)) {  // @第三个if  
                        redisTemplate.opsForValue().set(key, "0", getNowToNextDayMilliseconds(), TimeUnit.MILLISECONDS);
                    }
                    return getCode(key, redisTemplate.opsForValue().increment(key).toString());
                } else {
                    value = redisTemplate.opsForValue().get(key);
                    if (null != value) {// @第四个if  
                        return getCode(key, redisTemplate.opsForValue().increment(key).toString());
                    }
                }
            }
        } catch (InterruptedException e) {
            throw new BizException(BasicDataExceptionEnum.ORDER_CODE_CREATE_FAIL);
        } finally {
            if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }

    }

  对于这段代码的解读,其实关注4个if就可以了

第一个if

  如果值存在,直接自增返回,redis的incr本身是原子操作,且redis是单线程的,可以保证线程安全,同时也能保证多进程情况下,拿到的值是唯一的。

第二个if

  当值是不存在的时候,需要去set值了。这个操作不是原子性的,而且分布式的情况下,A实例的set可能把B实例set的值覆盖掉。这个时候需要一个分布式锁。redssion的lock实现了AQS的接口,可以通过tryLock去尝试获取分布式锁。如果获取锁成功,则执行下一步。

第三个if

  即使获取分布式锁成功,也需要考虑本地并发问题,主要是需要考虑临界区的线程问题,第一个拿到锁的执行完了,会释放锁,这个时候临界区等待的线程就可以拿到锁了,也会进到这段逻辑,所以需要在判空操作一下。

第四个if

  如果没有获取到锁,也没有必要继续去循环获取锁,因为这个时候,可能拿到锁的线程已经把初始值set进去了。所以这里再次判空操作一下。

测试

  要保证代码的严谨性,需要设计一个并发场景的测试

@Test
    public void get_order_code_multi_thread_test()throws Exception {
        //删掉key,模拟key不存在的情况下并发操作
        redisTemplate.opsForValue().getOperations().delete("IS");
        CyclicBarrier barrier = new CyclicBarrier(100);
        CountDownLatch latch = new CountDownLatch(100);
        Set<String> result= new HashSet<>(100);
        for (int i = 0; i < 100; i++) {
            new Thread(()->{
                try {
                    barrier.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } catch (BrokenBarrierException e) {
                    e.printStackTrace();
                }
                String code = commonBiz.getOrderCode("IS");
                System.out.println(code);
                result.add(code);
                latch.countDown();
            }).start();
        }
        latch.await();
        System.out.println(result.size());
        Assert.assertTrue(result.size()==100);
    }

  这里模拟了100个线程。通过CyclicBarrier来保证100个线程同时掉获取单号的操作。然后通过CountDownLatch保证100个线程都执行完,在判断执行的结果,获取的订单编号放到一个set里面,如果最终set的size是100个,说明100个线程在并发情况下,获取的单号没有重复,执行成功。

总结

  这个需求的难点其实是在凌晨这一刻,key失效的时候,多进程,同时同线程来set的问题。多进程通过分布式锁来保证只有一个进程操作,set不是操作,主要原因是get判断值为空和set一个0值进去,不是原子操作,其实有些集合提供的有putIfAbsent()此类的原子操作方法,因此只能通过锁来保证原子性。这里又复用了分布式锁的阻塞性来保证getAndSet的原子性,同时需要考虑临界区的问题,不能只关注第一个拿到锁的线程,还得考虑第一个线程释放锁后,第二个线程拿到锁的情况。

这篇关于分布式环境下redis自增值&定时失效的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!