据说损失了几百万。。。文章总结得很好:
1
aspromiss 2018 年 9 月 21 日
上周刚用过一次 keys 键前缀* 查询,惨痛教训
|
2
thechosenone 2018 年 9 月 21 日
长知识
|
3
echoZero 2018 年 9 月 21 日
我们之前一个同事 keys 一把 然后线上 redis 直接来了一波 Redis 超时
|
4
linxl 2018 年 9 月 21 日
keys 不能用, 那应该用什么?
|
6
wps353 2018 年 9 月 21 日
缓存雪崩
|
7
jiantalk 2018 年 9 月 21 日
Redis 是单线程要阻塞,我司的同学比较喜欢用这个,还好我们量不算大
|
8
mrgeneral 2018 年 9 月 21 日
正常啊 这个线上和容易超时,因为 redis 是单进程的。
封装一个 scan 命令就好了,正常命令行下的 scan 命令不太好用,得多次迭代才能找到 key |
10
sampeng 2018 年 9 月 21 日
keys 是肯定不能用的。。scan 才行。。。封装即可。。。。
|
11
misaka19000 2018 年 9 月 21 日
我们有同事用 medis 连到生产的库,这玩意一连上去就会自动执行 keys *来获取所有的 key,然后生产环境的 Redis 就主备切换了,还是挺危险的
|
12
CMGS 2018 年 9 月 21 日
keys 是全局锁……用 scan 可破
|
13
ghl 2018 年 9 月 21 日
@misaka19000 #11 medis 用的是 scan 吧,刚本地 monitor 确认了下确实没用 keys
|
14
misaka19000 2018 年 9 月 21 日
@ghl #13 是的 刚刚问了下他用的不是 medis,是另外一个工具
|
15
Ryoma 2018 年 9 月 21 日
直接把 keys 禁用就好了
|
16
aa6563679 2018 年 9 月 21 日 via iPhone
一直在用 keys....不过我这数据都存 hash 了 key 并不多
|
17
orangeade 2018 年 9 月 21 日
遇到过这个事故
|
18
Rosanta 2018 年 9 月 21 日
这命令直接禁用就行了,或者 rename 走
|
19
yaodong0126 2018 年 9 月 21 日
这个命令,我在自己封的 client 中,直接屏蔽掉了...
|
20
derrickT 2018 年 9 月 21 日
keys 是遍历所有的 key,key 多的时候当然会非常慢
|
21
tachikomachann 2018 年 9 月 21 日 via Android
我们线上一直是禁用这个的
|
22
Linxing 2018 年 9 月 21 日
所以 Keys 设计出来的意义是??
|
23
yueyoum 2018 年 9 月 21 日 所以现在工程师这么好做吗?
这是大概 4,5 年前 学习 redis 的时候, 准备用在产品中的 基础啊 |
24
dengtongcai 2018 年 9 月 21 日 via Android
会阻塞的!
|
25
pricelessLucky 2018 年 9 月 21 日
长知识了
|
26
kslr 2018 年 9 月 21 日
这一定是没看文档
|
27
xuanbg 2018 年 9 月 21 日
key 的数量只有千把个是没问题的,数量上万了就很危险了。hash 也一样,存对象似乎很方便,但如果一次要操作多个属性,还是序列化后存 string 更好。redis 虽然速度快,但读写次数多了也就不快了。连续读写 rides 十几次,可能还没读写一次 mysql 数据库快。
|
28
moonsn 2018 年 9 月 21 日 via iPhone
学到了,下周回去改代码😂
|
29
fundebug OP @moonsn1994 应该今天晚上改
|
30
unixbeta 2018 年 9 月 21 日 via iPhone
擦,现在这个时代还有技术跟不上业务的,真是可耻。
|
31
fanyingmao 2018 年 9 月 21 日 via Android
@xuanbg 用 string 的话感觉只读写少量属性,却操作了全部的数据,redis 读写数据量和次数哪个对性能消耗更大?要有数据量和次数消耗的比值才好权衡。
|
32
hcymk2 2018 年 9 月 21 日
|
33
yuatom 2018 年 9 月 21 日 via iPhone
生产环境不能用 keys,算是规范了吧。
|
34
Immortal 2018 年 9 月 22 日
一直以为这个是常识
和数据库 like 类似 |
35
sampeng 2018 年 9 月 22 日 via iPhone
@fanyingmao 记住 redis 是线程动物,所有性能和问题都是出于忘记这个事实。
读大数据量必然引起其他客户端操作延迟增大(大的 string),操作大的内部对象必然引起其他客户端操作延迟,甚至有严重的瓶颈(把大的 hash/list 全取出来) |
36
sampeng 2018 年 9 月 22 日 via iPhone
@fanyingmao 数据量单机不做特别操作,云主机有自己的限制,不是无上限。500 左右?具体得问云主机。自建的就看交换机能力了,千兆上下浮动。这个跑满,全部都得跪
|
37
kingcc 2018 年 9 月 22 日
文章末尾的开发建议总结的非常好,点赞
|
38
cpdyj0 2018 年 9 月 22 日 via Android
没实际用过 Redis,学生党,但最早接触到这玩意儿的时候就知道不能用 KEYS * 啊…… CPU 会被打满啊
|
39
karllynn 2018 年 9 月 22 日
用 scan 就行啊。。redis 应该提供配置直接禁用某些命令,哈
|
40
xuanbg 2018 年 9 月 22 日
@fanyingmao 有可能一次读取或更新超过 5 个属性的话,果断 string。hash 我一般都是用来存配置,就是为了减少 key 数量,另外,客户端连上去,也更容易管理。
|
41
lrh3321 2018 年 9 月 22 日 via Android
涨知识了
|