Redis *** 作一个设置过期时间的key

执行set命令的时候，你又重新设置了这个redis的key超时时间，如果你只是想第一次设置超时时间，可以把else语句里面直接更新这个key的value就可以了，不需要再设置超时时间。

else {

int i = IntegerparseInt(keyName_str);

i+=1;

redisServiceset(keyName,i+"");

}

redis> SET key value

OK

redis> EXP 工RE key 5

(integer) 1

redis> GET key // 5 秒之内

"value"

redis> GET key // 5 秒之后

(nil)

100版本后可用

时间复杂度： O(1)

给一个 key 设置超时时间。在一个超时时间结束后，这个键将会被自动删除。一个拥有关联过期时间的键在Redis术语里通常被认为 不稳定的 。

只有删除或者覆盖键的内容的命令，包括 DEL , SET , GETSET 和所有的 STORE 命令，才会把过期时间清除。这意味着从理论上讲，所有改变键上存储的值而不是使用新的值来替换的 *** 作，都将会保持过期时间不变。例如，使用 INCR 增加一个键的值，使用 LPUSH 讲一个新的值放到列表中，或者使用 HSET 改变一个哈希的字段的值都将会使过期时间保持不变。

使用 PERSIST 命令将一个键变成持久化的键，过期时间也会被清除。

如果一个键被 RENAME 重命名，关联的生存时间将会被转移到新的键名上。

如果一个键被 RENAME 重命名，就像在一个已经存在的键 Key_A ，它被一个调用 RENAME Key_B Key_A 所覆盖，原始的 Key_A 是否关联过期时间是没关系的，新的键 Key_A 将会继承 Key_B 的所有特征。

注意，使用负数调用 EXPIRE / PEXPIRE ，或者使用过去的时间调用 EXPIREAT / PEXPIREAT 将会使键被删除，而不是过期(相应的，d出的 key event 将会是 del ，而不是 expired )。

可以使用一个已经有过期时间集的键作为参数来调用 EXPIRE 。在这种情况下，一个键的生存时间已经 更新 为一个新值。对此很多应用，下面的 Navigation session 模式一节记录了一个例子。

在Redis 213之前的版本中，使用一个命令改变一个拥有过期时间的键的值，效果跟彻底移除这个键一样。这种语义是必须的，因为复制层的限制现在已经确定了。

EXPIRE 将会返回0，并且不会使用一个过期时间集合来改变一个键的过期时间。

特别的 返回数字 ：

redis> SET mykey "Hello"

redis> EXPIRE mykey 10

redis> TTL mykey

redis> SET mykey "Hello World"

redis> TTL mykey

redis>

想象你有一个网页服务，并且你对用户最近访问的N个页面有兴趣，这样每个临近的页面视图的执行时间不会超过前一个页面视图执行的60秒。理论上来讲，你可以认为用户访问的页面集合为 Navigation session ，其中就可以包含用户在寻找哪些他或她感兴趣的产品信息，因此你可以推荐关联的产品。

你可以非常容易的使用下面的策略在Redis中建模这种类型：每次用户访问一个页面你就调用下面的命令：

如果用户闲置超过60秒，这个键将会被删除，只有访问时间差值小于60秒的页面才会被记录。

这个模式可以很容易的修改为使用 INCR 做计数器来替代使用 RPUSH 的列表。

通常情况下创建Redis的键时不关联生存时间。这个键将会简单的一直生存，除非用户显示的删除它，例如使用 DEL 命令。

EXPIRE 家族命令能够把一个过期时间关联到一个给定的键，代价是这个键会使用额外的内存。当一个键设置了过期时间，Redis将会确保当指定的时间过去之后移除这个键。

一个键的生存时间可以被 EXPIRE 命令更新，或者被 PERSIST 命令完全移除(或其他严格相关的命令)。

在Redis24版本中，过期时间可能不是非常精确的，并且它可能是在0到1秒之间的出入。从Redis26版本开始，过期时间误差是从0到1毫秒。

键的过期信息以绝对的Unix时间戳形式保存(Redis26以及更新的版本毫秒内)。这意味着甚至当Redis实例未启动时时间就流走了。

为了过期时间能工作的很好，计算机时间必须保持稳定。如果你从两个时钟巨大不同步的计算机上移动一个RDB文件，有趣的事情将会发生(像所有的键在加载时变成过期)。

实际上运行中的实例将一直会检查计算机的时钟，举例来说，如果你给一个键设置1000秒的生存时间，然后在未来将你的计算机设置在2000秒以后，这个键将会立即失效，而不是持续1000秒。

Redis键将会通过两种方式过期：一个被动的方式，和一个主动的方式。

一个键的被动过期是很简单的，当一些客户端尝试访问它，然后这个键被发现超时了。

当然，这是不够的，因为有一些键将永远不会被再次访问。这些键无论如何都应该被过期。所以，Redis会定期的在过期的集合中随机范围内测试少量的键。所有的已过期的键将会被从键空间被删除。

这就是Redis会在每秒做10次的事情：

这是一个小概率的算法，基本的设想是我们的样本代表整个键空间，然后我们继续失效直到将要失效的键百分比小于25%。

这意味着在任何一个时刻，正在使用内存的已经过期的最大数量的键等于每秒最大写 *** 作数量除以4

为了获得正确的行为而不牺牲一致性，当一个键失效， DEL *** 作会同时在AOF文件和附属的副节点执行。这种方式失效进程是在主实例集中的，也不会出现一致性错误。

然而，当副本已经连接到主节点后将不会独立的失效键(但将会等待来自主节点的 DEL )，他们仍将会获取数据集中的全部过期状态，所以当一个副本被选举为主节点后，它将能够独立的失效这些键，完全像一个主节点。

使用场景：当redis某个key过期的时候，我们希望处理一些业务例如发消息或者取消订单等，当然也可以使用中间件mq来实现，之前的文章里有写rocketMq实现消息的通知和消费，这篇文章主要是用redis来实现

我们需要重写onMessage方法，当有key过期的时候这个方法可以获取获取的key，并处理自己的业务

如果我们是多台机器部署，那么我们还需要加锁 *** 作，避免消息的重复消费，这里利用了stringRedisTemplateopsForValue()setIfAbsent命令可以帮我们完成setnx加锁的 *** 作，如果为空set返回true,如果不为空返回false，因为redis是单线程所以可以保证只消费一次，setIfAbsent同时要加上过期时间，注意redis版本过低的话可能没有这个方法

理论上会删除，但是由于redis版本的问题或者说过期删除机制的问题，有很小很小的可能，一个key过期了但是却没被删除。

这种情况发生在，一个key你给人家设置了有效时间，但是却频繁去修改它的value，就有小小的可能会发生

以上就是关于Redis *** 作一个设置过期时间的key全部的内容，包括:Redis *** 作一个设置过期时间的key、redis怎么设置key的过期时间、Redis过期时间等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！