一、一个新闻
新闻大致标题:某工程师生产环境执行redis keys * 导致宕机!
说的是某公司IT部门发生年度PO级特大事故,造成公司经济损失400万,原因如下:
该工程师直接连生产redis库,执行如下命令:
keys * wxdb(此处省略)cf8*
运行后导致redis hang住,接着CPU飙升,业务上所有支付链路卡住,所有的请求流量全部挤压到了rds数据库中,引起数据库雪崩效应,进而直接宕机。
该公司表示,如再犯类似事故,将直接开除涉事员工,然后会逐步收回运维团队相关权限!
二、一个定律
在业内,redis开发规范中一般都有一条铁规:
线上Redis禁止使用Keys正则匹配操作!
然而知易行难,事故才会一而再再而三的发生。
三、分析原因
先说两句有用的废话:
1、redis是单线程的,其所有操作都是原子的,不会因为并发产生数据问题;
2、使用高耗时的Redis命令非常危险,会占用唯一线程的大量处理时间,导致其它的请求都处于等待状态。
有上面两句作铺垫,原因就显而易见了!
需要注意的是,同样危险的命令不仅有keys *,还有以下几组:
因此,一个合格的redis运维或者开发,应该懂得如何禁用上面的命令。所以我一直觉得出现新闻中那种情况的原因,一般是人员的水平问题。
四、怎么禁用这些命令呢?
就是在redis.conf中,在SECURITY这一项中,我们新增以下命令:
另外,对于FLUSHALL命令,需要设置配置文件中appendonly no,否则服务器是无法启动。
注意了,上面的这些命令可能有遗漏,大家可以查官方文档。除了Flushdb这类和redis安全隐患有关的命令意外,但凡发现时间复杂度为O(N)的命令,都要慎重,不要在生产上随便使用。例如hgetall、lrange、smembers、zrange、sinter等命令,它们并非不能使用,但这些命令的时间复杂度都为O(N),使用这些命令需要明确N的值,否则也会出现缓存宕机。
五、改良建议
业内建议使用scan命令来改良keys和SMEMBERS命令:
Redis2.8版本以后有了一个新命令scan,可以用来分批次扫描redis记录,这样肯定会导致整个查询消耗的总时间变大,但不会影响redis服务卡顿,影响服务使用。