Redis的keys命令到底有多慢？
keys命令的用法：
keys pattern
查找符合正則匹配的key的列表。掃描對象是Redis服務(wù)中所有的key，想想都很慢對不對？
同時(shí)執(zhí)行keys命令的同時(shí)，Redis進(jìn)程將被阻塞，無法執(zhí)行其他命令，假如超過了哨兵的down-after-milliseconds配置，還會進(jìn)行主從切換，切換過程中，如果主節(jié)點(diǎn)恢復(fù)正常，還可能出現(xiàn)腦裂等一系列問題。
所以，生產(chǎn)環(huán)境中，建議直接禁用keys命令。
Keys命令的替代方案
scan掃描，避免阻塞 將需要統(tǒng)計(jì)的數(shù)據(jù)放入一個set中 （但是這樣可能出現(xiàn)Big Key問題，一般數(shù)據(jù)量大就不推薦）
Keys命令在Redis Cluster中是怎樣執(zhí)行的？
一般來說，keys命令對于集群節(jié)點(diǎn)來說，是不知道路由到哪個節(jié)點(diǎn)的，不像 get命令。在Java的Jedis客戶端的JedisClusterKeyCommands類中，我們看到：
public Set<byte[]> keys(byte[] pattern) {
// 在每個節(jié)點(diǎn)執(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é)點(diǎn)上執(zhí)行keys命令，并將結(jié)果合并返回的。
本文既然將keys命令的慢，那么他到底有多慢呢？
Keys命令到底有多慢？
這里主要是給大家一個基本的概念，并不是深入剖析。
這是騰訊云上Redis集群服務(wù)中，慢查詢的日志。我們看到，Keys命令大概執(zhí)行了250ms ~ 300ms。
根據(jù)節(jié)點(diǎn)信息，我們看到，每個節(jié)點(diǎn)存儲了大約153w的key，占用內(nèi)存300M+，平均每個鍵值對占用內(nèi)存0.208KB，合213個字節(jié)。
根據(jù)我的理解，既然keys命令返回的是key值，而集群中其實(shí)有一個結(jié)構(gòu)slots_to_keys 記錄著所有key 的, 這只與key的數(shù)量有關(guān)，與Big key的關(guān)系不大。
按照這種猜想，假如此時(shí)Redis節(jié)點(diǎn)占用內(nèi)存為3G，且Key數(shù)量成比例，那么Keys命令執(zhí)行時(shí)間因?yàn)?s左右，這段時(shí)間Redis節(jié)點(diǎn)是阻塞的。
如何保護(hù) SpringBoot 配置文件中的敏感信息
Java 數(shù)組轉(zhuǎn) List 的三種方式及對比
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^
