淺談Redis的keys命令到底有多慢

Posted on by

keys命令的用法：

keys pattern

查找符合正則匹配的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命令內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：