keys命令的用法：

keys pattern

查找符合正則匹配的key的列表。掃描對象是Redis服務(wù)中所有的key，想想都很慢對不對？
同時執(zhí)行keys命令的同時，Redis進程將被阻塞，無法執(zhí)行其他命令，假如超過了哨兵的down-after-milliseconds配置，還會進行主從切換，切換過程中，如果主節(jié)點恢復(fù)正常，還可能出現(xiàn)腦裂等一系列問題。

所以，生產(chǎn)環(huán)境中，建議直接禁用keys命令。

Keys命令的替代方案

1、scan掃描，避免阻塞
2、將需要統(tǒng)計的數(shù)據(jù)放入一個set中 （但是這樣可能出現(xiàn)Big Key問題，一般數(shù)據(jù)量大就不推薦）

Keys命令在Redis Cluster中是怎樣執(zhí)行的？

一般來說，keys命令對于集群節(jié)點來說，是不知道路由到哪個節(jié)點的，不像 get命令。在Java的Jedis客戶端的JedisClusterKeyCommands類中，我們看到：

	public Set<byte[]> keys(byte[] pattern) {
		// 在每個節(jié)點執(zhí)行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是通過在每個節(jié)點上執(zhí)行keys命令，并將結(jié)果合并返回的。

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

Keys命令到底有多慢？

這里主要是給大家一個基本的概念，并不是深入剖析。

這是騰訊云上Redis集群服務(wù)中，慢查詢的日志。我們看到，Keys命令大概執(zhí)行了250ms ~ 300ms。

根據(jù)節(jié)點信息，我們看到，每個節(jié)點存儲了大約153w的key，占用內(nèi)存300M+，平均每個鍵值對占用內(nèi)存0.208KB，合213個字節(jié)。

根據(jù)我的理解，既然keys命令返回的是key值，而集群中其實有一個結(jié)構(gòu)slots_to_keys 記錄著所有key 的, 這只與key的數(shù)量有關(guān)，與Big key的關(guān)系不大。

按照這種猜想，假如此時Redis節(jié)點占用內(nèi)存為3G，且Key數(shù)量成比例，那么Keys命令執(zhí)行時間因為3s左右，這段時間Redis節(jié)點是阻塞的。

到此這篇關(guān)于淺談Redis的keys命令到底有多慢的文章就介紹到這了,更多相關(guān)Redis keys命令內(nèi)容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站！

美國穩(wěn)定服務(wù)器

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學(xué)習(xí)參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。