Redis爬坑记（一）：incr命令和expire命令的误区

要实现的功能：限制用户的每分钟的访问次数

一个有严重bug的代码：每次访问来了，就执行代码块二，当第一次访问，就走else语句，设置当前用户的次数为1，且设置该key的有效期是一分钟。
在一分钟之内，第二次来访问了，就走if语句了，因为redis存在这个key了，就实现自增一，然后取出来判断是否超过了设定的阈值。逻辑上看似看似没什么问题。

代码块一：

Long maxAllowedTimes = 100L;Long REQUEST_EXIT_MILLISECONDS = 60*1000L;

代码块二：

Jedis jedis = RedisUtils.getJedis();String requestKey = Times + ":" + ID + ":" + getId();if (jedis.exists(requestKey)) {    //???jedis.incr(requestKey);String times = jedis.get(requestKey);if (StringUtil.strIsNotEmpty(times)){if (Long.parseLong(times) > maxAllowedTimes) {jedis.del(requestKey);return true;}}} else {jedis.set(requestKey, "1");jedis.pexpire(requestKey,REQUEST_EXIT_MILLISECONDS);}

实际上问题来了，maxAllowedTimes给设置成1000次，而实际上每分钟没有超过1000次的去访问数也能return true。
这TM设置的key的有效期没起到作用啊。。。各种讲道理讲不通，也是醉了。。。

其实不然，经过查资料发现：

Redis Incr 命令将 key 中储存的数字值增一，如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作，且将key的有效时间设置为长期有效。

耶，这么说就对了。其实，即使判断了key是否存在if (jedis.exists(requestKey))，也不能保证在执行jedis.incr(requestKey)自增的时候key是存在的。问题就出在这里。

就是这么巧，当三个问号“//???”这里时，恰好key到期了，从redis中删除了，然后继续执行jedis.incr(requestKey)自增，这时候，key的value等于1，且key是长期有效的。
所以当前用户不管何时每次访问的时候（只要redis不重启），key始终是存在的，这样就会一直自增，自增，自增到1000次。就这样bug就出现了。

解决方案：得对症下药啊

Jedis jedis = RedisUtils.getJedis();String requestKey = Times + ":" + ID + ":" + getId();jedis.incr(requestKey);//如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作，且将key的有效时间设置为长期有效.String times = jedis.get(requestKey);if("1".equals(times)){jedis.pexpire(requestKey,REQUEST_EXIT_MILLISECONDS);//如果是第一次访问，设置key的有效时间} else if(StringUtils.isEmpty(times)){//如果key过期了，再incr（从第1次开始记录），再设置key的有效时间jedis.incr(requestKey);jedis.pexpire(requestKey,REQUEST_EXIT_MILLISECONDS);times = jedis.get(requestKey);}if (times != null && Long.parseLong(times) > maxAllowedTimes) {jedis.del(requestKey);return true;}

至此，问题解决。
这里只是给出了一种“限制用户的每分钟的访问次数”的实现方案，应该还有其他更安全跟有效的实现方案。如有，请赐教，一起学习讨论。

另外:

Redis Incrby 命令将 key 中储存的数字加上指定的增量值，如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。

Redis Hincrby 命令用于为哈希表中的字段值加上指定增量值。


友情链接：
redis实现访问频次限制的几种方式