为什么 Redis 密钥不会过期?
Why Redis keys are not expiring?
我已经检查了这些问题 但它们没有帮助我解决问题。我在使用 spring-data-redis 库的 Spring REST 应用程序中使用 Redis 作为速率限制的键值存储。我测试了巨大的负载。因为我使用以下代码来存储密钥并且我也设置了过期时间。大多数情况下,密钥会按预期过期。但有时密钥不会过期!
代码片段
RedisAtomicInteger counter = counter = new RedisAtomicInteger("mykey");
counter.expire(1, TimeUnit.MINUTES);
我使用 redis-cli 工具检查了密钥的可用性
keys *
和
ttl keyname
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 counter = counter = new 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 日志中,当我 "MONITOR" 它在
编辑:
现在有了更新的代码,我相信除了您报告的内容之外,您的方法存在根本性缺陷。
您实施它的方式需要在生产中 运行 KEYS
- 这很糟糕。当你向外扩展时,你将导致服务器上的系统负载不断增加,而且是不必要的。正如它上面的每一个文档所说,not 在生产中使用 keys
。请注意,在密钥名称中编码过期时间不会给您带来任何好处。如果您将密钥名称的那部分作为创建时间戳,甚至是随机数,则什么都不会改变。事实上,如果你删除了那一点,什么都不会改变。
更明智的方法是使用不依赖于时间的键名。使用过期为您处理该功能。让我们称您的限速为 "session"。没有时间戳的密钥名称是 "session ID"。通过在其上设置 60 秒的到期时间,它将在 61 秒标记时不再可用。因此,您可以安全地将结果递增并将结果与您的限制进行比较,而无需知道当前时间或到期时间。您只需要一个静态密钥名称和适当的过期设置。
如果您 INCR
一个不存在的键,Redis 将 return “1”,这意味着它创建了键并在单个 step/call 中递增了它。所以基本上逻辑是这样的:
- 创建"session" ID
- 使用 ID 增加计数器
- 将结果与极限进行比较
- 如果计数 == 1,将过期设置为 60 秒
- id 计数 > 限制,拒绝
步骤 3.1 很重要。计数为 1 表示这是 Redis 中的一个新密钥,并且您想为其设置过期时间。其他任何情况都意味着应该已经设置了到期时间。如果您在 3.2 中设置它,您将中断该过程,因为它将保留计数器超过 60 秒。
有了这个你就不需要基于过期时间的动态密钥名称,因此不需要使用 keys
来查明是否存在现有的 "session"限速对象。它还使您的代码更加简单和可预测,并减少到 Redis 的往返次数——这意味着它将降低 Redis 上的负载并提高性能。至于如何执行您正在使用的 w/the 客户端库,我不能说,因为我不太熟悉它。但是基本序列应该可以翻译成它,因为它相当基本和简单。
但是,您没有显示任何支持过期没有发生的断言的内容。您所做的只是表明 Redis 确实被告知并设置了过期时间。为了支持您的声明,您需要证明密钥不会过期。这意味着您需要在过期时间后显示密钥的检索,并且计数器不是 "reset" 过期后重新创建的。您可以看到过期发生的一种方法是使用 keyspace notifications。有了它,您将能够看到 Redis 说密钥已过期。
如果您执行多个 windows 速率限制,或者如果您有更大的 window(即 10 分钟),在这种情况下,排序集可能是一个更明智的选择来防止请求的前端加载 - 如果需要的话。但是正如您编写的示例,上面的代码将正常工作。
我已经检查了这些问题
代码片段
RedisAtomicInteger counter = counter = new RedisAtomicInteger("mykey");
counter.expire(1, TimeUnit.MINUTES);
我使用 redis-cli 工具检查了密钥的可用性
keys *
和
ttl keyname
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 counter = counter = new 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 日志中,当我 "MONITOR" 它在
编辑: 现在有了更新的代码,我相信除了您报告的内容之外,您的方法存在根本性缺陷。
您实施它的方式需要在生产中 运行 KEYS
- 这很糟糕。当你向外扩展时,你将导致服务器上的系统负载不断增加,而且是不必要的。正如它上面的每一个文档所说,not 在生产中使用 keys
。请注意,在密钥名称中编码过期时间不会给您带来任何好处。如果您将密钥名称的那部分作为创建时间戳,甚至是随机数,则什么都不会改变。事实上,如果你删除了那一点,什么都不会改变。
更明智的方法是使用不依赖于时间的键名。使用过期为您处理该功能。让我们称您的限速为 "session"。没有时间戳的密钥名称是 "session ID"。通过在其上设置 60 秒的到期时间,它将在 61 秒标记时不再可用。因此,您可以安全地将结果递增并将结果与您的限制进行比较,而无需知道当前时间或到期时间。您只需要一个静态密钥名称和适当的过期设置。
如果您 INCR
一个不存在的键,Redis 将 return “1”,这意味着它创建了键并在单个 step/call 中递增了它。所以基本上逻辑是这样的:
- 创建"session" ID
- 使用 ID 增加计数器
- 将结果与极限进行比较
- 如果计数 == 1,将过期设置为 60 秒
- id 计数 > 限制,拒绝
步骤 3.1 很重要。计数为 1 表示这是 Redis 中的一个新密钥,并且您想为其设置过期时间。其他任何情况都意味着应该已经设置了到期时间。如果您在 3.2 中设置它,您将中断该过程,因为它将保留计数器超过 60 秒。
有了这个你就不需要基于过期时间的动态密钥名称,因此不需要使用 keys
来查明是否存在现有的 "session"限速对象。它还使您的代码更加简单和可预测,并减少到 Redis 的往返次数——这意味着它将降低 Redis 上的负载并提高性能。至于如何执行您正在使用的 w/the 客户端库,我不能说,因为我不太熟悉它。但是基本序列应该可以翻译成它,因为它相当基本和简单。
但是,您没有显示任何支持过期没有发生的断言的内容。您所做的只是表明 Redis 确实被告知并设置了过期时间。为了支持您的声明,您需要证明密钥不会过期。这意味着您需要在过期时间后显示密钥的检索,并且计数器不是 "reset" 过期后重新创建的。您可以看到过期发生的一种方法是使用 keyspace notifications。有了它,您将能够看到 Redis 说密钥已过期。
如果您执行多个 windows 速率限制,或者如果您有更大的 window(即 10 分钟),在这种情况下,排序集可能是一个更明智的选择来防止请求的前端加载 - 如果需要的话。但是正如您编写的示例,上面的代码将正常工作。