redis的expire方法

EXPIRE key seconds（单位/秒） 为给定 key 设置生存时间，当 key 过期时(生存时间为 0 )，它会被自动删除。在 Redis 中，带有生存时间的 key 被称为『易失的』(volatile)。

生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆写(overwrite)，这意味着，如果一个命令只是修改(alter)一个带生存时间的 key 的值而不是用一个新的 key 值来代替(replace)它的话，那么生存时间不会被改变。

比如说，对一个 key 执行 INCR 命令，对一个列表进行 LPUSH 命令，或者对一个哈希表执行 HSET 命令，这类 *** 作都不会修改 key 本身的生存时间。

另一方面，如果使用 RENAME 对一个 key 进行改名，那么改名后的 key 的生存时间和改名前一样。

RENAME 命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。

使用 PERSIST 命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个『持久的』(persistent) key 。

前文中,介绍了String数据类型的一些常用的命令,那么下面来看一下一些针对列表与集合的常用命令

列表是Redis中另外一种数据类型,下面我们来看看列表中一些基本的 *** 作命令

语法如下:

将一个或多个值插入到列表key的表头,如果有多个value,则会按从左到右的顺序依次插入表头,具体使用如下:

来看一下上面的命令,我在第一次执行的时候,报了一个错,因为我们之前k1对应的值不是一个list,就会报错

第二点,lpush命令的返回值是push *** 作后的list的长度,如上面,我第一次push了3个value进去, 长度就是3,然后又加了两个那长度就是5

返回列表key中的指定 区间内的元素,区间以偏移量start和stop指定,start和stop都以0开始,即0代表第一个元素,1代表第二个元素 以此类推,也可以使用负数作为下标,以-1表示列表的最后一个元素,-2表示倒数第二个元素 以此类推,具体使用如下:

rpush和lpush的功能基本一致,只不过rpush中,value是按照从右到左的顺序依次插入的,使用如下:

rpop命令,可以移除列表中最后一个元素,并且返回该元素的值,使用如下:

lpop和rpop类似,只不过移除的是列表中的第一个元素,使用如下:

lindex命令,可以返回指定下标对应的元素的值,可以用正数下标,0表示第一个元素,也可以用负数下标, -1表示最后一个元素,使用如下:

ltrim命令,可以对一个列表进行修剪,需要指定一个下标开始值和结束值, 不在这个区间的元素都会被删除掉, 下标的取值和上面都一样的,使用如下:

BLPOP是阻塞式列表的d出原语,blpop是lpop的阻塞版本

当给定列表内,没有任何元素可以供d出的时候,连接将被blpop命令阻塞, 当 给定的是多个key时,按参数key的先后顺序依次检查各个列表,d出一个非空列表的第一个元素

使用这个命令的时候,需要指定阻塞的时长,单位是秒,如果在规定时间内没有元素可供d出,则阻塞结束,返回结果是key-value的组合,具体使用如下:

来看一下上面的命令,最开始集合是有三个元素的,然后每次给定阻塞时长是5秒,d出第一个元素,然后一共执行三次,列表中也就没有元素了,这时候,执行第四次d出的 *** 作,就可以看到,这里阻塞了5秒中之后,发现,还是没有可以d出的元素,然后就阻塞结束,返回nil了

接下来看一些针对集合的 *** 作命令

sadd命令,可以添加一个或多个指定的member元素到集合的key中, 如果值在这个集合中存在的话就忽略掉,如果集合key不存在就先新建集合,然后添加member元素到集合,具体使用如下:

第一个命令添加了v1,v2,然后下面又去添加v2,是直接被忽略掉了,已经存在的元素不会被加进去, 这里的返回值是新添加到集合里的元素的数量,不包括已经存在于集合中的元素

srem命令可以在key集合中移除指定的元素,如果指定的元素不存在,则忽略,如果key集合不存在,则被视为一个空的集合,返回0,使用如下:

sismember可以返回指定的值,是不是这个key里面的成员 ,使用如下:

v3是不在k1这个集合中的, 所以返回0 , v2存在,就返回1

scard 命令可以返回指定集合中的元素的数量,如下:

可以看到,最开始元素的数量是1,然后添加一个元素进去,再查一下就是2了

smember命令,可以返回指定key集合中的所有元素,如下:

srandmember命令,传入key的名称,然后会随机返回key集合中的一个元素,从redis26开始,这个命令可以指定返回元素的个数(count)

count参数详解:

如下:

spop命令和srandmember类似,不同的是 spop每次返回的元素都会被从这个集合中移除掉,如下:

sdiff用来取两个集合的差集,如下:

sdiffstore和sdiff命令基本一致,不同的是会把返回的结果保存在一个新的集合中,使用如下:

sinter命令,用来计算指定集合的交集,如下:

sinterstore命令,和上面的sinter类似,但是会把返回值保存到一个新的集合中,如下:

用来计算集合的并集,如下:

sunionstore和sunion类似,但是会把返回结果保存在一个新的集合中,如下:

关于list和set的一些常用命令就说这么多,主要就是一些添加,删除,交集并集差集的 *** 作

从业务服务器到Redis服务器这条调用链路中变慢的原因可能有2个

但是大多数情况下都是Redis服务的问题。但是应该如何衡量Redis变慢了呢？命令执行时间大于1s，大于2s？这其实并没有一个固定的标准。

例如在一个配置较高的服务器中，05毫秒就认为Redis变慢了，在一个配置较低的服务器中，3毫秒才认为Redis变慢了。所以我们要针对自己的机器做基准测试，看平常情况下Redis处理命令的时间是多长？

我们可以使用如下命令来监测和统计测试期间的最大延迟（以微秒为单位）

比如执行如下命令

参数中的60是测试执行的秒数，可以看到最大延迟为3725微秒（3毫秒左右），如果命令的执行远超3毫秒，此时Redis就有可能很慢了！

那么Redis有哪些慢 *** 作呢？

Redis的各种命令是在一个线程中依次执行的，如果一个命令在Redis中执行的时间过长，就会影响整体的性能，因为后面的请求要等到前面的请求被处理完才能被处理，这些耗时的 *** 作有如下几个部分

Redis可以通过日志记录那些耗时长的命令，使用如下配置即可

执行如下命令，就可以查询到最近记录的慢日志

之前的文章我们已经介绍了Redis的底层数据结构，它们的时间复杂度如下表所示

名称 时间复杂度 dict（字典） O(1) ziplist （压缩列表） O(n) zskiplist （跳表） O(logN) quicklist（快速列表） O(n) intset（整数集合） O(n)

「单元素 *** 作」 ：对集合中的元素进行增删改查 *** 作和底层数据结构相关，如对字典进行增删改查时间复杂度为O(1)，对跳表进行增删查时间复杂为O(logN)

「范围 *** 作」 ：对集合进行遍历 *** 作，比如Hash类型的HGETALL，Set类型的SMEMBERS，List类型的LRANGE，ZSet类型的ZRANGE，时间复杂度为O(n)，避免使用，用SCAN系列命令代替。（hash用hscan，set用sscan，zset用zscan）

「聚合 *** 作」 ：这类 *** 作的时间复杂度通常大于O(n)，比如SORT、SUNION、ZUNIONSTORE

「统计 *** 作」 ：当想获取集合中的元素个数时，如LLEN或者SCARD，时间复杂度为O(1)，因为它们的底层数据结构如quicklist，dict，intset保存了元素的个数

「边界 *** 作」 ：list底层是用quicklist实现的，quicklist保存了链表的头尾节点，因此对链表的头尾节点进行 *** 作，时间复杂度为O(1)，如LPOP、RPOP、LPUSH、RPUSH

「当想获取Redis中的key时，避免使用keys 」 ，Redis中保存的键值对是保存在一个字典中的（和Java中的HashMap类似，也是通过数组+链表的方式实现的），key的类型都是string，value的类型可以是string，set，list等

例如当我们执行如下命令后，redis的字典结构如下

我们可以用keys命令来查询Redis中特定的key，如下所示

keys命令的复杂度是O(n)，它会遍历这个dict中的所有key，如果Redis中存的key非常多，所有读写Redis的指令都会被延迟等待，所以千万不用在生产环境用这个命令（如果你已经准备离职的话，祝你玩的开心）。

「既然不让你用keys，肯定有替代品，那就是scan」

scan是通过游标逐步遍历的，因此不会长时间阻塞Redis

「用用zscan遍历zset，hscan遍历hash，sscan遍历set的原理和scan命令类似，因为hash，set，zset的底层实现的数据结构中都有dict。」

「如果一个key对应的value非常大，那么这个key就被称为bigkey。写入bigkey在分配内存时需要消耗更长的时间。同样，删除bigkey释放内存也需要消耗更长的时间」

如果在慢日志中发现了SET/DEL这种复杂度不高的命令，此时你就应该排查一下是否是由于写入bigkey导致的。

「如何定位bigkey」

Redis提供了扫描bigkey的命令

可以看到命令的输入有如下3个部分

这个命令的原理就是redis在内部执行了scan命令，遍历实例中所有的key，然后正对key的类型，分别执行strlen，llen，hlen，scard，zcard命令，来获取string类型的长度，容器类型（list，hash，set，zset）的元素个数

使用这个命令需要注意如下两个问题

「如何解决bigkey带来的性能问题？」

我们可以给Redis中的key设置过期时间，那么当key过期了，它在什么时候会被删除呢？

「如果让我们写Redis过期策略，我们会想到如下三种方案」

定时删除策略对CPU不友好，当过期键比较多的时候，Redis线程用来删除过期键，会影响正常请求的响应

惰性删除读CPU是比较有好的，但是会浪费大量的内存。如果一个key设置过期时间放到内存中，但是没有被访问到，那么它会一直存在内存中

定期删除策略则对CPU和内存都比较友好

redis过期key的删除策略选择了如下两种

「惰性删除」 客户端在访问key的时候，对key的过期时间进行校验，如果过期了就立即删除

「定期删除」 Redis会将设置了过期时间的key放在一个独立的字典中，定时遍历这个字典来删除过期的key，遍历策略如下

「因为Redis中过期的key是由主线程删除的，为了不阻塞用户的请求，所以删除过期key的时候是少量多次」 。源码可以参考expirec中的activeExpireCycle方法

为了避免主线程一直在删除key，我们可以采用如下两种方案

Redis是一个内存数据库，当Redis使用的内存超过物理内存的限制后，内存数据会和磁盘产生频繁的交换，交换会导致Redis性能急剧下降。所以在生产环境中我们通过配置参数maxmemoey来限制使用的内存大小。

当实际使用的内存超过maxmemoey后，Redis提供了如下几种可选策略。

「Redis的淘汰策略也是在主线程中执行的。但内存超过Redis上限后，每次写入都需要淘汰一些key，导致请求时间变长」

可以通过如下几个方式进行改善

Redis的持久化机制有RDB快照和AOF日志，每次写命令之后后，Redis提供了如下三种刷盘机制

「当aof的刷盘机制为always，redis每处理一次写命令，都会把写命令刷到磁盘中才返回，整个过程是在Redis主线程中进行的，势必会拖慢redis的性能」

当aof的刷盘机制为everysec，redis写完内存后就返回，刷盘 *** 作是放到后台线程中去执行的，后台线程每隔1秒把内存中的数据刷到磁盘中

当aof的刷盘机制为no，宕机后可能会造成部分数据丢失，一般不采用。

「一般情况下，aof刷盘机制配置为everysec即可」

在持久化一节中，我们已经提到 「Redis生成rdb文件和aof日志重写，都是通过主线程fork子进程的方式，让子进程来执行的，主线程的内存越大，阻塞时间越长。」

可以通过如下方式优化

当机器的内存不够时， *** 作系统会将部分内存的数据置换到磁盘上，这块磁盘区域就是Swap分区，当应用程序再次访问这些数据的时候，就需要从磁盘上读取，导致性能严重下降

「当Redis性能急剧下降时就有可能是数据被换到Swap分区，我们该如何排查Redis数据是否被换到Swap分区呢？」

每一行Size表示Redis所用的一块内存大小，Size下面的Swap表示这块大小的内存，有多少已经被换到磁盘上了，如果这2个值相等，说明这块内存的数据都已经被换到磁盘上了

我们可以通过如下方式来解决

最后我们总结一下Redis的慢 *** 作

String、Hash、List、Set和Zset。

等同于java中的， Map<String,String> string 是redis里面的最基本的数据类型，一个key对应一个value。

应用场景 ：String是最常用的一种数据类型，普通的key/value存储都可以归为此类，如用户信息，登录信息和配置信息等；

实现方式 ：String在redis内部存储默认就是一个字符串，被redisObject所引用，当遇到incr、decr等 *** 作（自增自减等原子 *** 作）时会转成数值型进行计算，此时redisObject的encoding字段为int。

Redis虽然是用C语言写的，但却没有直接用C语言的字符串，而是自己实现了一套字符串。目的就是为了提升速度，提升性能。 Redis构建了一个叫做简单动态字符串（Simple Dynamic String），简称SDS。

Redis的字符串也会遵守C语言的字符串的实现规则，即 最后一个字符为空字符。然而这个空字符不会被计算在len里头。

Redis动态扩展步骤：

Redis字符串的性能优势

常用命令 ：set/get/decr/incr/mget等，具体如下；

ps：计数器（字符串的内容为整数的时候可以使用），如 set number 1。

补充：

等同于java中的： Map<String,Map<String,String>> ，redis的hash是一个string类型的field和value的映射表， 特别适合存储对象。 在redis中，hash因为是一个集合，所以有两层。第一层是key：hash集合value，第二层是hashkey：string value。所以判断是否采用hash的时候可以参照有两层key的设计来做参考。并且注意的是， 设置过期时间只能在第一层的key上面设置。

应用场景 ：我们要存储一个用户信息对象数据，其中包括用户ID、用户姓名、年龄和生日，通过用户ID我们希望获取该用户的姓名或者年龄或者生日；

实现方式 ：Redis的Hash实际是内部存储的Value为一个HashMap，并提供了直接存取这个Map成员的接口。如，Key是用户ID, value是一个Map。 这个Map的key是成员的属性名，value是属性值 。这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 就可以 *** 作对应属性数据。 当前HashMap的实现有两种方式 ：当HashMap的成员比较少时Redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的HashMap结构，这时对应的value的redisObject的encoding为zipmap，当成员数量增大时会自动转成真正的HashMap,此时redisObject的encoding字段为int。

常用命令 ：hget/hset/hgetall等，具体如下：

等同于java中的 Map<String,List<String>> ，list 底层是一个链表，在redis中，插入list中的值，只需要找到list的key即可，而不需要像hash一样插入两层的key。 list是一种有序的、可重复的集合。

应用场景 ：Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现；

实现方式 ：Redis list的实现为一个 双向链表 ，即可以支持反向查找和遍历，更方便 *** 作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括 发送缓冲队列 等也都是用的这个数据结构。

常用命令 ：lpush/rpush/lpop/rpop/lrange等，具体如下：

性能总结 :

它是一个字符串链表，left、right都可以插入添加。

等同于java中的 Map<String,Set<String>> ，Set 是一种无序的，不能重复的集合。并且在redis中，只有一个key它的底层由hashTable实现的，天生去重。

应用场景 ：Redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动去重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且 set提供了判断某个成员是否在一个set集合内的重要接口 ，这个也是list所不能提供的；如保存一些标签的名字。标签的名字不可以重复，顺序是可以无序的。

实现方式 ：set 的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

常用命令 ：sadd/spop/smembers/sunion等，具体如下：

ZSet(Sorted Set：有序集合) 每个元素都会关联一个double类型的分数score，分数允许重复，集合元素按照score排序（ 当score相同的时候，会按照被插入的键的字典顺序进行排序 ），还可以通过 score 的范围来获取元素的列表。

应用场景 ：Redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以 通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。 当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。

底层实现 ： zset 是 Redis 提供的一个非常特别的数据结构，常用作排行榜等功能，以用户 id 为 value ，关注时间或者分数作为 score 进行排序。实现机制分别是 zipList 和 skipList 。规则如下：

zipList：满足以下两个条件

skipList：不满足以上两个条件时使用跳表、组合了hash和skipList

为什么用skiplist不用平衡树？

主要从内存占用、对范围查找的支持和实现难易程度这三方面总结的原因。

拓展：mysql为什么不用跳表？

常用命令 ：zadd/zrange/zrem/zcard等；

官网地址： >

如何查看redis最近使用的命令

使用Redis的脚本功能实现Redis中数据简单查询，有需要的朋友可以参考下。 在Redis的设计中，key是一切，对于Redis是可见的，而value对于Redis来说就是一个字节数组，Redis并不知道你的value中存储的是什么，所以要想实现比如 ‘select from users where userlocation="shanghai"’ 这样的查询，在Redis是没办法通过value进行比较得出结果的。但是可以通过不同的数据结构类型来做到这一点。比如如下的数据定义 users:1 {name:Jack,age:28,location:shanghai} users:2 {name:Frank,age:30,location:beijing} users:location:shanghai [1] 其中users:1 users:2 分别定义了两个用户信息，通过Redis中的hash数据结构，而users:location:shanghai 记录了所有上海的用户id，通过集合数据结构实现。这样通过两次简单的Redis命令调用就可以实现我们上面的查询。 Jedis jedis = jedisPoolgetResource(); Set<String> shanghaiIDs = jedissmembers("users:location:shanghai"); //遍历该set // //通过hgetall获取对应的user信息 jedishgetAll("users:" + shanghaiIDs[0]);

一般是根据需求来进行设置。

redis通过expire命令来设置key的过期时间。

语法：redisexpire(key, expiration)

1 在小于213的redis版本里，只能对key设置一次expire。redis213和之后的版本里，可以多次对key使用expire命令，更新key的expire time。

2 redis术语里面，把设置了expire time的key 叫做：volatile keys。 意思就是不稳定的key。

3 如果对key使用set或del命令，那么也会移除expire time。尤其是set命令，这个在编写程序的时候需要注意一下。

4 redis213之前的老版本里，如果对volatile keys 做相关写入 *** 作(LPUSH,LSET)，和其他一些触发修改value的 *** 作时，redis会删除该key。 也就是说 ：

redisexpire(key,expiration);

redislpush(key,field,value);

redisget(key) //return null

redis213之后的版本里面没有这个约束，可以任意修改。

redisset(key,100);

redisexpire(key,expiration);

redisincr(key)

redisget(key)

//redis222 return 101; redis<213 return 1;

5 redis对过期键采用了lazy expiration：在访问key的时候判定key是否过期，如果过期，则进行过期处理。其次，每秒对volatile keys 进行抽样测试，如果有过期键，那么对所有过期key进行处理。

锁的作用，我想大家都理解，就是让不同的线程或者进程可以安全地 *** 作共享资源，而不会产生冲突。

比较熟悉的就是 Synchronized 和 ReentrantLock 等，这些可以保证同一个 jvm 程序中，不同线程安全 *** 作共享资源。

但是在分布式系统中，这种方式就失效了；由于分布式系统多线程、多进程并且分布在不同机器上，这将使单机并发控制锁策略失效，为了解决这个问题就需要一种跨 JVM 的互斥机制来控制共享资源的访问。

比较常用的分布式锁有三种实现方式：

本篇文章主要讲解基于 Redis 分布式锁的实现。

分布式锁最主要的作用就是保证任意一个时刻，只有一个客户端能访问共享资源。

我们知道 redis 有 SET key value NX 命令，仅在不存在 key 的时候才能被执行成功，保证多个客户端只有一个能执行成功，相当于获取锁。

释放锁的时候，只需要删除 del key 这个 key 就行了。

上面的实现看似已经满足要求了，但是忘了考虑在分布式环境下，有以下问题：

最大的问题就是因为客户端或者网络问题，导致 redis 中的 key 没有删除，锁无法释放，因此其他客户端无法获取到锁。

针对上面的情况，使用了下面命令:

使用 PX 的命令，给 key 添加一个自动过期时间(30秒)，保证即使因为意外情况，没有调用释放锁的方法，锁也会自动释放，其他客户端仍然可以获取到锁。

注意给这个 key 设置的值 my_random_value 是一个随机值，而且必须保证这个值在客户端必须是唯一的。这个值的作用是为了更加安全地释放锁。

这是为了避免删除其他客户端成功获取的锁。考虑下面情况：

因此这里使用一个 my_random_value 随机值，保证客户端只会释放自己获取的锁，即只删除自己设置的 key 。

这种实现方式，存在下面问题：

上面章节介绍了，简单实现存在的问题，下面来介绍一下 Redisson 实现又是怎么解决的这些问题的。

主要关注 tryAcquireOnceAsync 方法，有三个参数:

方法主要流程:

这个方法的流程与 tryLock(long waitTime, long leaseTime, TimeUnit unit) 方法基本相同。

这个方法与 tryAcquireOnceAsync 方法的区别，就是一个获取锁过期时间，一个是能否获取锁。即 获取锁过期时间 为 null 表示获取到锁，其他表示没有获取到锁。

获取锁最终都会调用这个方法，通过 lua 脚本与 redis 进行交互，来实现分布式锁。

首先分析，传给 lua 脚本的参数：

lua 脚本的流程:

为了实现无限制持有锁，那么就需要定时刷新锁的过期时间。

这个类最重要的是两个成员属性：

使用一个静态并发集合 EXPIRATION_RENEWAL_MAP 来存储所有锁对应的 ExpirationEntry ，当有新的 ExpirationEntry 并存入到 EXPIRATION_RENEWAL_MAP 集合中时，需要调用 renewExpiration 方法，来刷新过期时间。

创建一个超时任务 Timeout task ，超时时间是 internalLockLeaseTime / 3 , 过了这个时间，即调用 renewExpirationAsync(threadId) 方法，来刷新锁的过期时间。

判断如果是当前线程持有的锁，那么就重新设置过期时间，并返回 1 即 true 。否则返回 0 即 false 。

通过调用 unlockInnerAsync(threadId) 来删除 redis 中的 key 来释放锁。特别注意一点，当不是持有锁的线程释放锁时引起的失败，不需要调用 cancelExpirationRenewal 方法，取消定时，因为锁还是被其他线程持有。

传给这个 lua 脚本的值：

这个 lua 脚本的流程：

调用了 LockPubSub 的 subscribe 进行订阅。

这个方法的作用就是向 redis 发起订阅，但是对于同一个锁的同一个客户端(即 一个 jvm 系统) 只会发起一次订阅，同一个客户端的其他等待同一个锁的线程会记录在 RedissonLockEntry 中。

方法流程：

只有当 counter >= permits 的时候，回调 listener 才会运行，起到控制 listener 运行的效果。

释放一个控制量，让其中一个回调 listener 能够运行。

主要属性：

这个过程对应的 redis 中监控的命令日志:

因为看门狗的默认时间是 30 秒，而定时刷新程序的时间是看门狗时间的 1/3 即 10 秒钟，示例程序休眠了 15 秒，导致触发了刷新锁的过期时间 *** 作。

注意 rLocktryLock(10, TimeUnitSECONDS); 时间要设置大一点，如果等待时间太短，小于获取锁 redis 命令的时间，那么就直接返回获取锁失败了。

分析源码我们了解 Redisson 模式的分布式，解决了锁过期时间和可重入的问题。但是针对 redis 本身可能存在的单点失败问题，其实是没有解决的。

基于这个问题， redis 作者提出了一种叫做 Redlock 算法, 但是这种算法本身也是有点问题的，想了解更多，请看 基于Redis的分布式锁到底安全吗

以上就是关于redis的expire方法全部的内容，包括:redis的expire方法、Redis-5-列表与集合的一些常用命令、Redis有哪些慢 *** 作等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！