劝你少用Redis的keys命令

wptr33 2025-03-10 21:10 21 浏览

最近巡查项目线上日志时发现，Redis偶尔会抛出这种连接超时的异常，虽然只是短暂性的连接超时没有造成什么实质性的影响，但是本着尽职尽责的原则（其实是怕组长找上门）还是查找了一番。

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

异常分析：

通过日志的详细分析发现，Redis是连接成功的，但是在执行某些命令的时候就会出现超时现象，并且是偶发性的
持续时间也不长。而Jedis默认设置的超时时常是2秒，而Redis执行命令时又是单线程的，那会不会哪个命令执行超过了2秒，导致阻塞了后面的命令执行呢？

通过 slowlog get 10 命令查看最近10条慢查询日志，发现keys这条命令执行时间超过了2秒，而经过测试发现在执行keys命令时确实会导致其他命令请求超时。

至此就找到了问题的所在了，keys命令执行时间超过了2秒导致其他命令阻塞。

1.时间复杂度

KEYS 命令的时间复杂度为 O(N)，其中 N 是数据库中键的数量。这是因为 Redis 需要遍历整个数据库来查找匹配指定模式的键。当数据库中的键数量较少时，KEYS 命令的性能通常是可以接受的。

2.阻塞操作

由于 KEYS 命令需要遍历整个数据库，它会阻塞 Redis 服务器的其他操作。在执行 KEYS 命令期间，Redis 无法处理其他命令请求，这可能导致其他客户端的延迟增加。因此，在处理大型数据库或者在生产环境中，不推荐频繁使用 KEYS 命令。

3.内存消耗

KEYS 命令在执行期间需要将匹配的键保存在内存中。如果匹配的键较多或者键的值较大，KEYS 命令可能会消耗大量的内存。这可能导致 Redis 服务器的内存占用过高，并且可能触发 Redis 的内存淘汰机制(eviction)，从而导致键被随机删除。

4.遍历时间

由于 KEYS 命令需要遍历整个数据库，它的执行时间与数据库中键的数量成正比。因此，如果数据库非常大，执行时间可能会很长。这可能会导致客户端请求超时或者导致 Redis 在一段时间内无法响应其他命令请求。

根据官方给出的文档说明可以考使用SCAN 命令。SCAN 命令使用游标迭代方式逐步返回匹配的键，避免了一次性遍历整个数据库的性能问题。

redis keys