淺談Redis的keys命令到底有多慢
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)文章希望大家以后多多支持本站!
版權(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處理。