redis做缓存，怎么取出全部key

redis做缓存的时候，怎么取出全部相同前缀的key，百度到很多都是keys,scan

获取当前库下的所有key

可以使用 keys 命令，keys支持模糊匹配，但是cpu使用率有点高。还有一种就是scan命令

设置一个set，在缓存的时候把数据的key存到这个set里面

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

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

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

EXPIRE key second

设置超时 key 。超时过期后，key将自动删除。在Redis术语中，通常认为具有超时的key是 不稳定的 。

只有删除或覆盖key内容的命令才能清除超时，包括 DEL ， SET ， GETSET 和所有 STORE 命令。这意味着 改变 存储在key中的值而不用新key替换它的所有 *** 作将使超时保持不变。举例来说，增加一键的值 INCR ，往列表推新值的，包括 LPUSH ，或改变了哈希的字段值 HSET ，都不会改变超时。

也可以清除超时，使用 PERSIST 命令将key重新转换为持久key。

如果使用 RENAME 重命名key，则相关的生存时间将转移到新key名称。

如果一个key被 RENAME 覆盖，比如，已经存在key Key_A ，被如下命令所覆盖， RENAME Key_B Key_A ，新key Key_A 将继承所有的 Key_B 的属性，与原始 Key_A 否有超时没有关系。

请注意，使用非正数的超时时间调用 EXPIRE / PEXPIRE 或 使用一个过去时间调用 EXPIREAT / PEXPIREAT ，将导致键被 删除 而不是过期（因此，发出的 键事件 将是 del ，而不是 expired ）。

可以使用已经设置超时的key作为参数调用 EXPIRE 。在这种情况下，key的生存时间将 更新 为新值。有许多有用的应用程序，下面的 导航会话 模式部分中记录了一个示例 。

在之前的Redis 213版本中 ，使用命令更改key来使用超时设置更改key，具有完全删除key的效果。由于复制层中的限制现在已得到修复，因此需要使用此语义。

EXPIRE 将返回0并且不会更改具有超时设置的key的超时。

整数回复 ，具体为：

假如你有一个web服务，你需要记录用户最近浏览的N个页面，每个相邻页面的浏览时间不超过60s。

你可以用redis轻松实现，每次用户打开一个页面，执行如下命令：

如果用户60s没有 *** 作，页面就会被删除，只有60s以内的页面会被记录。

通常，创建Redis key时没有相关的过期时间。key只会永远存在，除非用户以明确的方式将其 删除 ，例如使用 DEL 命令。

EXPIRE 家族命令能够给key设置超时时间，但是会使用一些额外的内存成本。当key设置了过期时，Redis将确保在指定的时间过后删除key。

可以使用 EXPIRE 和 PERSIST 命令（或其他严格相关的命令）更新或完全删除key生存时间。

在Redis 24中，到期可能不精确，误差可能在0到1秒之间。

从Redis 26开始，到期误差从0到1毫秒。

Key到期信息存储为绝对Unix时间戳（在Redis 26或更高版本的情况下以毫秒为单位）。这意味着即使Redis实例未处于活动状态，时间也在流动。

为了使到期效果良好，计算机时间必须稳定。如果您从两台计时器中移动RDB文件并在其时钟中使用大型desync，则可能会发生有趣的事情（例如加载时加载的所有键都将在加载时过期）。

即使运行实例也会检查计算机时钟，例如，如果您设置的key的生存时间为1000秒，然后将计算机时间设置为当前时间向后2000秒，key将立即过期，而不是持续1000秒。

Redis key以两种方式过期：被动方式和主动方式。

当某个客户端尝试访问key时，如果发现key超时，key被动过期。

当然这还不够，因为有过期的key永远不会被再次访问。这些key无论如何都应该过期，所以周期性地Redis会在具有过期设置的key中随机测试几个key。已经过期的所有key都将从key空间中删除。

具体来说，这就是Redis每秒做10次的事情：

这是一个简单的概率算法，基本上假设我们的样本代表整个key空间，我们继续到期，直到可能过期的key百分比低于25％

这意味着在任何给定时刻，使用内存的已经过期的最大key数量最大等于每秒最大写入 *** 作量除以4。

为了在不牺牲一致性的情况下获得正确的行为，当key到期时，在AOF文件中合成 DEL *** 作并通知所有副本节点。这样，到期过程集中在主实例中，并且不存在一致性错误。

但是，连接到主服务器的副本节点不会单独地使key过期，（但会等待来自主服务器的 DEL ），但它们仍将采用数据集中存在的过期的完整状态，因此当副本被选为主服务器时它将能够独立地使密钥到期，充分充当主人。

Redis作为内存数据库，拥有非常高的性能，单个实例的QPS能够达到10W左右。但我们在使用Redis时，经常时不时会出现访问延迟很大的情况，如果你不知道Redis的内部实现原理，在排查问题时就会一头雾水。

很多时候，Redis出现访问延迟变大，都与我们的使用不当或运维不合理导致的。

下面我们就来分析一下Redis在使用过程中，经常会遇到的延迟问题以及如何定位和分析。

如果在使用Redis时，发现访问延迟突然增大，如何进行排查？

首先，第一步，建议你去查看一下Redis的慢日志。Redis提供了慢日志命令的统计功能，我们通过以下设置，就可以查看有哪些命令在执行时延迟比较大。

首先设置Redis的慢日志阈值，只有超过阈值的命令才会被记录，这里的单位是微妙，例如设置慢日志的阈值为5毫秒，同时设置只保留最近1000条慢日志记录：

# 命令执行超过5毫秒记录慢日志

CONFIG SET slowlog-log-slower-than 5000

# 只保留最近1000条慢日志

CONFIG SET slowlog-max-len 1000

设置完成之后，所有执行的命令如果延迟大于5毫秒，都会被Redis记录下来，我们执行SLOWLOG get 5查询最近5条慢日志：

127001:6379> SLOWLOG get 5

1) 1) (integer) 32693 # 慢日志ID

2) (integer) 1593763337 # 执行时间

3) (integer) 5299 # 执行耗时(微妙)

4) 1) 'LRANGE' # 具体执行的命令和参数

2) 'user_list_2000'

3) '0'

4) '-1'

2) 1) (integer) 32692

2) (integer) 1593763337

3) (integer) 5044

4) 1) 'GET'

2) 'book_price_1000'

通过查看慢日志记录，我们就可以知道在什么时间执行哪些命令比较耗时， 如果你的业务经常使用O(n)以上复杂度的命令， 例如sort、sunion、zunionstore，或者在执行O(n)命令时 *** 作的数据量比较大，这些情况下Redis处理数据时就会很耗时。

如果你的服务请求量并不大，但Redis实例的CPU使用率很高，很有可能是使用了复杂度高的命令导致的。

解决方案就是，不使用这些复杂度较高的命令，并且一次不要获取太多的数据，每次尽量 *** 作少量的数据，让Redis可以及时处理返回。

如果查询慢日志发现，并不是复杂度较高的命令导致的，例如都是SET、DELETE *** 作出现在慢日志记录中，那么你就要怀疑是否存在Redis写入了大key的情况。

Redis在写入数据时，需要为新的数据分配内存，当从Redis中删除数据时，它会释放对应的内存空间。

如果一个key写入的数据非常大，Redis 在分配内存时也会比较耗时。 同样的，当删除这个key的数据时， 释放内存也会耗时比较久。

你需要检查你的业务代码，是否存在写入大key的情况，需要评估写入数据量的大小，业务层应该避免一个key存入过大的数据量。

那么有没有什么办法可以扫描现在Redis中是否存在大key的数据吗？

Redis也提供了扫描大key的方法：

redis-cli -h $host -p $port --bigkeys -i 001

使用上面的命令就可以扫描出整个实例key大小的分布情况，它是以类型维度来展示的。

需要注意的是当我们在线上实例进行大key扫描时，Redis的QPS会突增，为了降低扫描过程中对Redis的影响，我们需要控制扫描的频率，使用-i参数控制即可，它表示扫描过程中每次扫描的时间间隔，单位是秒。

使用这个命令的原理，其实就是Redis在内部执行scan命令，遍历所有key，然后针对不同类型的key执行strlen、llen、hlen、scard、zcard来获取字符串的长度以及容器类型(list/dict/set/zset)的元素个数。

而对于容器类型的key，只能扫描出元素最多的key，但元素最多的key不一定占用内存最多，这一点需要我们注意下。不过使用这个命令一般我们是可以对整个实例中key的分布情况有比较清晰的了解。

针对大key的问题，Redis官方在40版本推出了lazy-free的机制，用于异步释放大key的内存，降低对Redis性能的影响。即使这样，我们也不建议使用大key，大key在集群的迁移过程中，也会影响到迁移的性能，这个后面在介绍集群相关的文章时，会再详细介绍到。

有时你会发现，平时在使用Redis时没有延时比较大的情况，但在某个时间点突然出现一波延时，而且 报慢的时间点很有规律，例如某个整点，或者间隔多久就会发生一次。

如果出现这种情况，就需要考虑是否存在大量key集中过期的情况。

如果有大量的key在某个固定时间点集中过期，在这个时间点访问Redis时，就有可能导致延迟增加。

Redis的过期策略采用主动过期+懒惰过期两种策略：

注意， Redis的主动过期的定时任务，也是在Redis主线程中执行的 ，也就是说如果在执行主动过期的过程中，出现了需要大量删除过期key的情况，那么在业务访问时，必须等这个过期任务执行结束，才可以处理业务请求。此时就会出现，业务访问延时增大的问题，最大延迟为25毫秒。

而且这个访问延迟的情况， 不会记录在慢日志里。 慢日志中 只记录真正执行某个命令的耗时 ，Redis主动过期策略执行在 *** 作命令之前，如果 *** 作命令耗时达不到慢日志阈值，它是不会计算在慢日志统计中的，但我们的业务却感到了延迟增大。

此时你需要检查你的业务，是否真的存在集中过期的代码，一般集中过期使用的命令是expireat或pexpireat命令，在代码中搜索这个关键字就可以了。

如果你的业务确实需要集中过期掉某些key，又不想导致Redis发生抖动，有什么优化方案？

解决方案是， 在集中过期时增加一个随机时间，把这些需要过期的key的时间打散即可。

伪代码可以这么写：

# 在过期时间点之后的5分钟内随机过期掉

redisexpireat(key, expire_time + random(300))

这样Redis在处理过期时，不会因为集中删除key导致压力过大，阻塞主线程。

另外，除了业务使用需要注意此问题之外，还可以通过运维手段来及时发现这种情况。

我们需要对这个指标监控，当在 很短时间内这个指标出现突增 时，需要及时报警出来，然后与业务报慢的时间点对比分析，确认时间是否一致，如果一致，则可以认为确实是因为这个原因导致的延迟增大。

有时我们把Redis当做纯缓存使用，就会给实例设置一个内存上限maxmemory，然后开启LRU淘汰策略。

当实例的内存达到了maxmemory后，你会发现之后的每次写入新的数据，有可能变慢了。

导致变慢的原因是，当Redis内存达到maxmemory后，每次写入新的数据之前，必须先踢出一部分数据，让内存维持在maxmemory之下。

这个踢出旧数据的逻辑也是需要消耗时间的，而具体耗时的长短，要取决于配置的淘汰策略：

具体使用哪种策略，需要根据业务场景来决定。

我们最常使用的一般是allkeys-lru或volatile-lru策略，它们的处理逻辑是，每次从实例中随机取出一批key（可配置），然后淘汰一个最少访问的key，之后把剩下的key暂存到一个池子中，继续随机取出一批key，并与之前池子中的key比较，再淘汰一个最少访问的key。以此循环，直到内存降到maxmemory之下。

如果使用的是allkeys-random或volatile-random策略，那么就会快很多，因为是随机淘汰，那么就少了比较key访问频率时间的消耗了，随机拿出一批key后直接淘汰即可，因此这个策略要比上面的LRU策略执行快一些。

但以上这些逻辑都是在访问Redis时，真正命令执行之前执行的，也就是它会影响我们访问Redis时执行的命令。

另外，如果此时Redis实例中有存储大key，那么在淘汰大key释放内存时，这个耗时会更加久，延迟更大，这需要我们格外注意。

如果你的业务访问量非常大，并且必须设置maxmemory限制实例的内存上限，同时面临淘汰key导致延迟增大的的情况，要想缓解这种情况，除了上面说的避免存储大key、使用随机淘汰策略之外，也可以考虑拆分实例的方法来缓解，拆分实例可以把一个实例淘汰key的压力分摊到多个实例上，可以在一定程度降低延迟。

如果你的Redis开启了自动生成RDB和AOF重写功能，那么有可能在后台生成RDB和AOF重写时导致Redis的访问延迟增大，而等这些任务执行完毕后，延迟情况消失。

遇到这种情况，一般就是执行生成RDB和AOF重写任务导致的。

生成RDB和AOF都需要父进程fork出一个子进程进行数据的持久化，在fork执行过程中，父进程需要拷贝内存页表给子进程，如果整个实例内存占用很大，那么需要拷贝的内存页表会比较耗时，此过程会消耗大量的CPU资源，在完成fork之前，整个实例会被阻塞住，无法处理任何请求，如果此时CPU资源紧张，那么fork的时间会更长，甚至达到秒级。这会严重影响Redis的性能。

具体原理也可以参考我之前写的文章：Redis持久化是如何做的？RDB和AOF对比分析。

我们可以执行info命令，查看最后一次fork执行的耗时latest_fork_usec，单位微妙。这个时间就是整个实例阻塞无法处理请求的时间。

除了因为备份的原因生成RDB之外，在 主从节点第一次建立数据同步时 ，主节点也会生成RDB文件给从节点进行一次全量同步，这时也会对Redis产生性能影响。

要想避免这种情况，我们需要规划好数据备份的周期，建议 在从节点上执行备份，而且最好放在低峰期执行。 如果对于丢失数据不敏感的业务，那么不建议开启AOF和AOF重写功能。

另外，fork的耗时也与系统有关，如果把Redis部署在虚拟机上，那么这个时间也会增大。所以使用Redis时建议部署在物理机上，降低fork的影响。

很多时候，我们在部署服务时，为了提高性能，降低程序在使用多个CPU时上下文切换的性能损耗，一般会采用进程绑定CPU的 *** 作。

但在使用Redis时，我们不建议这么干，原因如下。

绑定CPU的Redis，在进行数据持久化时，fork出的子进程，子进程会继承父进程的CPU使用偏好，而此时子进程会消耗大量的CPU资源进行数据持久化，子进程会与主进程发生CPU争抢，这也会导致主进程的CPU资源不足访问延迟增大。

所以在部署Redis进程时，如果需要开启RDB和AOF重写机制，一定不能进行CPU绑定 *** 作！

上面提到了，当执行AOF文件重写时会因为fork执行耗时导致Redis延迟增大，除了这个之外，如果开启AOF机制，设置的策略不合理，也会导致性能问题。

开启AOF后，Redis会把写入的命令实时写入到文件中，但写入文件的过程是先写入内存，等内存中的数据超过一定阈值或达到一定时间后，内存中的内容才会被真正写入到磁盘中。

AOF为了保证文件写入磁盘的安全性，提供了3种刷盘机制：

当使用第一种机制appendfsync always时，Redis每处理一次写命令，都会把这个命令写入磁盘，而且 这个 *** 作是在主线程中执行的。

内存中的的数据写入磁盘，这个会加重磁盘的IO负担， *** 作磁盘成本要比 *** 作内存的代价大得多。如果写入量很大，那么每次更新都会写入磁盘，此时机器的磁盘IO就会非常高，拖慢Redis的性能，因此我们不建议使用这种机制。

与第一种机制对比，appendfsync everysec会每隔1秒刷盘，而appendfsync no取决于 *** 作系统的刷盘时间，安全性不高。因此我们推荐使用appendfsync everysec这种方式，在最坏的情况下，只会丢失1秒的数据，但它能保持较好的访问性能。

当然，对于有些业务场景，对丢失数据并不敏感，也可以不开启AOF。

如果你发现Redis突然变得非常慢， 每次访问的耗时都达到了几百毫秒甚至秒级 ，那此时就检查Redis是否使用到了Swap，这种情况下Redis基本上已经无法提供高性能的服务。

我们知道， *** 作系统提供了Swap机制，目的是为了当内存不足时，可以把一部分内存中的数据换到磁盘上，以达到对内存使用的缓冲。

但当内存中的数据被换到磁盘上后，访问这些数据就需要从磁盘中读取，这个速度要比内存慢太多！

尤其是针对Redis这种高性能的内存数据库来说，如果Redis中的内存被换到磁盘上，对于Redis这种性能极其敏感的数据库，这个 *** 作时间是无法接受的。

我们需要检查机器的内存使用情况，确认是否确实是因为内存不足导致使用到了Swap。

如果确实使用到了Swap，要及时整理内存空间，释放出足够的内存供Redis使用，然后释放Redis的Swap，让Redis重新使用内存。

释放Redis的Swap过程通常要重启实例，为了避免重启实例对业务的影响，一般先进行主从切换，然后释放旧主节点的Swap，重新启动服务，待数据同步完成后，再切换回主节点即可。

可见，当Redis使用到Swap后，此时的Redis的高性能基本被废掉，所以我们需要提前预防这种情况。

我们需要对Redis机器的内存和Swap使用情况进行监控，在内存不足和使用到Swap时及时报警出来，及时进行相应的处理。

如果以上产生性能问题的场景，你都规避掉了，而且Redis也稳定运行了很长时间，但在某个时间点之后开始，访问Redis开始变慢了，而且一直持续到现在，这种情况是什么原因导致的？

之前我们就遇到这种问题， 特点就是从某个时间点之后就开始变慢，并且一直持续。 这时你需要检查一下机器的网卡流量，是否存在网卡流量被跑满的情况。

网卡负载过高，在网络层和TCP层就会出现数据发送延迟、数据丢包等情况。Redis的高性能除了内存之外，就在于网络IO，请求量突增会导致网卡负载变高。

如果出现这种情况，你需要排查这个机器上的哪个Redis实例的流量过大占满了网络带宽，然后确认流量突增是否属于业务正常情况，如果属于那就需要及时扩容或迁移实例，避免这个机器的其他实例受到影响。

运维层面，我们需要对机器的各项指标增加监控，包括网络流量，在达到阈值时提前报警，及时与业务确认并扩容。

以上我们总结了Redis中常见的可能导致延迟增大甚至阻塞的场景，这其中既涉及到了业务的使用问题，也涉及到Redis的运维问题。

可见，要想保证Redis高性能的运行，其中涉及到CPU、内存、网络，甚至磁盘的方方面面，其中还包括 *** 作系统的相关特性的使用。

作为开发人员，我们需要了解Redis的运行机制，例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等，使用合理的命令，并结合业务场景进行优化。

作为DBA运维人员，需要了解数据持久化、 *** 作系统fork原理、Swap机制等，并对Redis的容量进行合理规划，预留足够的机器资源，对机器做好完善的监控，才能保证Redis的稳定运行。

在上文中，主要讲解了 Redis 常见的导致变慢的场景以及问题定位和分析，主要是由业务使用不合理和运维不当导致的。

在这篇文章中，我们来讲一讲Redis的数据结构和通用命令。

Redis支持多种不同的数据结构，包括5种基础数据结构和几种比较复杂的数据，这些数据结构可以满足不同的应用场景。

五种基础数据结构

复杂的数据结构

不同数据结构的相同之处

从上面的介绍，我们看到支持的数据结构的不同，但其实，Redis的每一种数据结构都由一个key和value组成,可以抽象为：

Redis数据结构组成

而所有数据结构的key的值都是任意合法的字符串,不同的数据结构的区别就在于value存储的值的不同而不同。

比如，最简简单的String数据结构，其value为String，所以String可以表示为：

而Hash数据结构，其value为一个哈希列表，所以Hash可以表示为：

这里就列出String和Hash来讲解说明，关于更多数据结构的内部结构及详细 *** 作，我们在之后的文章在再谈谈吧。

Redis官网将Redis的命令按照功能划分为15个主题分组,其中，Kyes主题的命令对所有的数据结构都通用，因此，有必要在了解其他数据结构命令前好好学习一下。

keys

keys命令的作用是列出Redis所有的key,该命令的时间复杂度为 O(N) ， N 随着Redis中key的数量增加而增加，因此Redis有大量的key，keys命令会执行很长时间，而由于Redis是单线程，某个命令耗费过长时间，则会导致后面的的所有请求无法得到响应，因此，千万不要在生产服务器上使用keys命令。

示例

exists

exists命令用于判断一个或多个key是否存在，判断多个key时，key之间用空格分隔,exists的返回值为整数，表示当前判断有多少个key是存在的。

示例

del

del命令用于删除一个或多个key，多个key之间用空格分隔，其返回值为整数，表示成功删除了多少个存在的key，因此，如果只删除一个key，则可以从返回值中判断是否成功，如果删除多个key，则只能得到删除成功的数量。

示例

expire,pexpire

expire设置key在多少秒之后过期，pexpire设置key在多少毫秒之后过期,成功返回1，失败返回0。

示例

ttl,pttl

ttl和pttl命令用于获取key的过期时间，其返回值为整型，代表的意义分为几种情况：

示例(ttl的演示，pttl类似)

expireat,pexpireat

设置key在某个时间戳过期,expreat参数时间戳用秒表示，而pexpireat则用毫秒表示，与expire和pexpire功能类似，返回1表示成功，0表示失败。

示例

persist

移除key的过期时间，将key设置为永久有效，当key设置了过期时间，使用persist命令移除后返回1，如果key不存在或本身就是永久有效的，则返回0。

示例

type

判断key是什么类型的数据结构,返回值为string,list,set,hash,zset,分别表示我们前面介绍的Redis的5种基础数据结构。

示例

上面介绍的是Redis中最常用的通用命令，虽然简单，但还是非常有必要掌握其用法和使用方面要注意的事项，其实，对于普通开发人员来说，很多时候，也只是使用这些基础通用的命令来 *** 作Redis而已。

首先要链接redis客户端

redis-cli

然后要通过key来查找你存的数据，相当于一个数组，有key，有value，通过key来查看value的值。

keys 注：列出当前redis存储的全部key。

keys W 注：列出当前redis存储的key名里第一个是“W”的全部key。

找到key名字后，就可以查看key里存了什么值了。

get WXOX 注：WXOX是你查出来的key的名字。

然后就可以看到WXOX里存了什么东西了，可能存了一个字符串，也可能存了一个对象，要是空的话，就会输出nil，意思是啥也没有！

以上就是关于redis做缓存，怎么取出全部key全部的内容，包括:redis做缓存，怎么取出全部key、SpringBoot实现Redis失效监听事件—KeyExpirationEventMessageListener、Redis官方教程 Expire超时等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！