公司新來一個 CTO:禁止使用 Redis 中的 keys 命令,發(fā)現(xiàn)即開除!
點擊關(guān)注公眾號，Java干貨
及時送達
推薦閱讀：
公司新來一個 CTO：禁止使用 Redis 中的 keys 命令，發(fā)現(xiàn)即開除！
keys命令的用法：
keys?pattern
查找符合正則匹配的key的列表。掃描對象是Redis服務中所有的key，想想都很慢對不對？
同時執(zhí)行keys命令的同時，Redis進程將被阻塞，無法執(zhí)行其他命令，假如超過了哨兵的down-after-milliseconds配置，還會進行主從切換，切換過程中，如果主節(jié)點恢復正常，還可能出現(xiàn)腦裂等一系列問題。
所以，生產(chǎn)環(huán)境中，建議直接禁用keys命令。
Keys命令的替代方案
- scan掃描，避免阻塞
- 將需要統(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命令的慢，那么他到底有多慢呢？另外，如果你近期準備面試跳槽，建議在Java面試庫小程序在線刷題，涵蓋 2000+?道 Java 面試題，幾乎覆蓋了所有主流技術(shù)面試題。
Keys命令到底有多慢？
這是騰訊云上Redis集群服務中，慢查詢的日志。我們看到，Keys命令大概執(zhí)行了250ms ~ 300ms。
根據(jù)節(jié)點信息，我們看到，每個節(jié)點存儲了大約153w的key，占用內(nèi)存300M+，平均每個鍵值對占用內(nèi)存0.208KB，合213個字節(jié)。
按照這種猜想，假如此時Redis節(jié)點占用內(nèi)存為3G，且Key數(shù)量成比例，那么Keys命令執(zhí)行時間因為3s左右，這段時間Redis節(jié)點是阻塞的。
原文鏈接：https://blog.csdn.net/weixin_37968613/article/details/119065777
版權(quán)聲明：本文為CSDN博主「c&0xff00」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
End
Spring Cloud Alibaba 最新重磅發(fā)布！
Stream 中的 map、peek、foreach 方法的區(qū)別？
Spring Cloud 微服務最新課程！