redis 的 KEYS 命令不能乱用啊...

上周刚用过一次 keys 键前缀* 查询，惨痛教训

长知识

我们之前一个同事 keys 一把 然后线上 redis 直接来了一波 Redis 超时

keys 不能用， 那应该用什么？

@linxl 刚刚看完这个文章 说是换 scan

缓存雪崩

正常啊 这个线上和容易超时，因为 redis 是单进程的。

封装一个 scan 命令就好了，正常命令行下的 scan 命令不太好用，得多次迭代才能找到 key

@mht 哈，看到了

keys 是肯定不能用的。。scan 才行。。。封装即可。。。。

我们有同事用 medis 连到生产的库，这玩意一连上去就会自动执行 keys *来获取所有的 key，然后生产环境的 Redis 就主备切换了，还是挺危险的

keys 是全局锁……用 scan 可破

@misaka19000 #11 medis 用的是 scan 吧，刚本地 monitor 确认了下确实没用 keys

@ghl #13 是的 刚刚问了下他用的不是 medis，是另外一个工具

直接把 keys 禁用就好了

一直在用 keys....不过我这数据都存 hash 了 key 并不多

遇到过这个事故

这命令直接禁用就行了，或者 rename 走

这个命令，我在自己封的 client 中，直接屏蔽掉了...

keys 是遍历所有的 key，key 多的时候当然会非常慢

我们线上一直是禁用这个的

所以 Keys 设计出来的意义是？？

所以现在工程师这么好做吗？

这是大概 4，5 年前 学习 redis 的时候， 准备用在产品中的 基础啊

会阻塞的！

长知识了

这一定是没看文档

key 的数量只有千把个是没问题的，数量上万了就很危险了。hash 也一样，存对象似乎很方便，但如果一次要操作多个属性，还是序列化后存 string 更好。redis 虽然速度快，但读写次数多了也就不快了。连续读写 rides 十几次，可能还没读写一次 mysql 数据库快。

学到了，下周回去改代码

@moonsn1994 应该今天晚上改

擦，现在这个时代还有技术跟不上业务的，真是可耻。

@xuanbg 用 string 的话感觉只读写少量属性，却操作了全部的数据，redis 读写数据量和次数哪个对性能消耗更大？要有数据量和次数消耗的比值才好权衡。

生产环境不能用 keys，算是规范了吧。

一直以为这个是常识
和数据库 like 类似

@fanyingmao 记住 redis 是线程动物，所有性能和问题都是出于忘记这个事实。

读大数据量必然引起其他客户端操作延迟增大(大的 string)，操作大的内部对象必然引起其他客户端操作延迟，甚至有严重的瓶颈(把大的 hash/list 全取出来)

@fanyingmao 数据量单机不做特别操作，云主机有自己的限制，不是无上限。500 左右？具体得问云主机。自建的就看交换机能力了，千兆上下浮动。这个跑满，全部都得跪

文章末尾的开发建议总结的非常好，点赞

没实际用过 Redis，学生党，但最早接触到这玩意儿的时候就知道不能用 KEYS * 啊…… CPU 会被打满啊

用 scan 就行啊。。redis 应该提供配置直接禁用某些命令，哈

@fanyingmao 有可能一次读取或更新超过 5 个属性的话，果断 string。hash 我一般都是用来存配置，就是为了减少 key 数量，另外，客户端连上去，也更容易管理。

涨知识了