浅谈Redis的keys命令到底有多慢

keys命令的用法：

查找符合正则匹配的key的列表。扫描对象是Redis服务中所有的key，想一想都很慢对不对？
同时履行keys命令的同时，Redis进程将被阻塞，没法履行其他命令，假设超过了哨兵的down-after-milliseconds配置，还会进行主从切换，切换进程中，如果主节点恢复正常，还可能出现脑裂等一系列问题。

所以，生产环境中，建议直接禁用keys命令。

Keys命令的替换方案

1、scan扫描，避免阻塞
2、将需要统计的数据放入一个set中 （但是这样可能出现Big Key问题，一般数据量大就不推荐）

Keys命令在Redis Cluster中是怎样履行的？

一般来讲，keys命令对集群节点来讲，是不知道路由到哪一个节点的，不像 get命令。在Java的Jedis客户真个JedisClusterKeyCommands类中，我们看到：

	public Set<byte[]> keys(byte[] pattern) {
		// 在每一个节点履行keys命令
		Collection<Set<byte[]>> keysPerNode = connection.getClusterCommandExecutor()
				.executeCommandOnAllNodes((JedisClusterCommandCallback<Set<byte[]>>) client -> client.keys(pattern))
				.resultsAsList();
		// 合并成一个整体后返回
		Set<byte[]> keys = new HashSet<>();
		for (Set<byte[]> keySet : keysPerNode) {
			keys.addAll(keySet);
		}
		return keys;
	}

我们看到，Jedis是通过在每一个节点上履行keys命令，并将结果合并返回的。

本文既然将keys命令的慢，那末他到底有多慢呢？

Keys命令到底有多慢？

这里主要是给大家一个基本的概念，其实不是深入剖析。

这是腾讯云上Redis集群服务中，慢查询的日志。我们看到，Keys命令大概履行了250ms ~ 300ms。

根据节点信息，我们看到，每一个节点存储了大约153w的key，占用内存300M+，平均每一个键值对占用内存0.208KB，合213个字节。

根据我的理解，既然keys命令返回的是key值，而集群中其实有一个结构slots_to_keys 记录着所有key 的, 这只与key的数量有关，与Big key的关系不大。

依照这类料想，假设此时Redis节点占用内存为3G，且Key数量成比例，那末Keys命令履行时间由于3s左右，这段时间Redis节点是阻塞的。

到此这篇关于浅谈Redis的keys命令到底有多慢的文章就介绍到这了,更多相关Redis keys命令内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！