为什么Redis密钥没有过期？

Question

代码段

RedisAtomicInteger counter = counter = new RedisAtomicInteger("mykey");
counter.expire(1, TimeUnit.MINUTES);

我使用redis-cli工具检查了密钥的可用性

钥匙*

而且

ttl密钥名

redis.conf具有默认值。

有什么建议吗？

编辑1：

完整代码：

功能在一个方面

public synchronized Object checkLimit(ProceedingJoinPoint joinPoint) throws Exception, Throwable {

        boolean isKeyAvailable = false;
        List<String> keysList = new ArrayList<>();

        Object[] obj = joinPoint.getArgs();
        String randomKey = (String) obj[1];
        int randomLimit = (Integer) obj[2];

        // for RedisTemplate it is already loaded as 

        // @Autowired
        // private RedisTemplate template; 

        // in this class
        Set<String> redisKeys = template.keys(randomKey+"_"randomLimit+"*");
        Iterator<String> it = redisKeys.iterator();
        while (it.hasNext()) {
               String data = it.next();
               keysList.add(data);
        }

        if (keysList.size() > 0) {
            isKeyAvailable = keysList.get(0).contains(randomKey + "_" + randomLimit);
        }

        RedisAtomicInteger counter = null;
        // if the key is not there
        if (!isKeyAvailable) {
              long expiryTimeStamp = 0;
              int timePeriodInMintes = 1;
              expiryTimeStamp = new Date(System.currentTimeMillis() + timePeriodInMintes * 60 * 1000).getTime();
              counter = new RedisAtomicInteger(randomKey+ "_"+ randomLimit + "_" + expiryTimeStamp,template.getConnectionFactory());
              counter.incrementAndGet();
              counter.expire(timePeriodInMintes, TimeUnit.MINUTES);
              break;

        } else {

              String[] keys = keysList.get(0).split("_");
              String rLimit = keys[1];

              counter = new RedisAtomicInteger(keysList.get(0), template.getConnectionFactory());
              int count = counter.get();
              // If count exceeds throw error
              if (count != 0 && count >= Integer.parseInt(rLimit)) {
                    throw new Exception("Error");
               }  
               else {
                    counter.incrementAndGet();
              }
      }
        return joinPoint.proceed();
    }

当这些线路运行时

RedisAtomicInteger计数器=计数器=新RedisAtomicInteger（“MyKey”）；Counter.Expire(1,TimeUnit.Minutes）；

我能看见

75672562.380127 [0 10.0.3.133:65462] "KEYS" "mykey_1000*"
75672562.384267 [0 10.0.3.133:65462] "GET" "mykey_1000_1475672621787"
75672562.388856 [0 10.0.3.133:65462] "SET" "mykey_1000_1475672621787" "0"
75672562.391867 [0 10.0.3.133:65462] "INCRBY" "mykey_1000_1475672621787" "1"
75672562.395922 [0 10.0.3.133:65462] "PEXPIRE" "mykey_1000_1475672621787" "60000"
...
75672562.691723 [0 10.0.3.133:65462] "KEYS" "mykey_1000*"
75672562.695562 [0 10.0.3.133:65462] "GET" "mykey_1000_1475672621787"
75672562.695855 [0 10.0.3.133:65462] "GET" "mykey_1000_1475672621787"
75672562.696139 [0 10.0.3.133:65462] "INCRBY" "mykey_1000_1475672621787" "1" 

在Redis日志中，当我在

Answer 1

编辑：现在，随着更新的代码，我相信你的方法从根本上来说是有缺陷的，除了你所报告的。

您实现它的方式需要在生产中运行keys-这是很糟糕的。当您向外扩展时，您将在服务器上造成不断增长的、不必要的系统阻塞负载。正如上面的文档所说，不要在生产中使用keys。请注意，在密钥名称中编码过期时间不会给您带来任何好处。如果您将键名的那一部分设置为创建时间戳，或者甚至是一个随机数，那么什么都不会改变。事实上，如果你移除了那一位，什么也不会改变。

更明智的方法是使用不依赖于时间的密钥名。过期的使用为您处理了该功能。让我们把你的限价活动称为“会话”。您的密钥名（没有时间戳）是“会话ID”。通过在其上设置60秒的过期时间，它将不再在61秒标记处可用。因此您可以安全地递增并将结果与您的限制进行比较,而不需要知道当前时间或过期时间。您所需要的只是一个静态密钥名称和一个适当的到期设置。

如果incr是一个不存在的键，Redis将返回“1”，这意味着它在一个步骤/调用中创建了该键并增加了它。所以基本上逻辑是这样的：

1. 创建“会话”ID
2. 使用ID递增计数器
3. 将结果与限制进行比较
   1. 如果计数==1，请将过期时间设置为60s
   2. ID计数>限制，拒绝

   步骤3.1很重要。计数为1意味着这是Redis中的一个新密钥，并且您希望在它上设置您的到期时间。任何其他内容都意味着过期时间应该已经设置好了。如果您在3.2中设置它，您将中断该进程，因为它将保留计数器60秒以上。

   这样，您就不需要根据过期时间拥有动态密钥名称，因此也就不需要使用keys来查找速率受限对象是否存在“会话”。它还使您的代码变得更加简单和可预测，并且减少到Redis的往返行程--这意味着它在Redis上的负载更低，性能更好。至于如何使用您正在使用客户机库，我不能说，因为我不太熟悉它。但是基本的序列应该是可以翻译的，因为它是相当基本和简单的。

   但是，您没有显示任何东西来支持过期没有发生的断言。您所做的只是表明Redis确实被告知并设置了一个到期时间。为了支持您的声明，您需要显示密钥没有过期。这意味着您需要在过期时间后显示密钥的检索，并且计数器没有在过期后通过重新创建而“重置”。您可以看到过期正在发生的一种方法是使用键空间通知。这样你就可以看到Redis说一把钥匙过期了。

   如果您使用多个窗口进行速率限制，或者如果您有一个更大的窗口（即10分钟），那么如果需要，排序集可能是一个更明智的选项来防止请求的前加载，那么这个过程就会失败一点。但是在编写示例时，上面的操作将会很好。