敢在线上Redis做Keys正则匹配操作！

一、一个新闻

新闻大致标题：某工程师生产环境执行redis keys * 导致宕机！

说的是某公司IT部门发生年度PO级特大事故，造成公司经济损失400万，原因如下：

该工程师直接连生产redis库，执行如下命令：

keys * wxdb（此处省略）cf8*

运行后导致redis hang住，接着CPU飙升，业务上所有支付链路卡住，所有的请求流量全部挤压到了rds数据库中，引起数据库雪崩效应，进而直接宕机。

该公司表示，如再犯类似事故，将直接开除涉事员工，然后会逐步收回运维团队相关权限！

二、一个定律

在业内，redis开发规范中一般都有一条铁规：

线上Redis禁止使用Keys正则匹配操作！

然而知易行难，事故才会一而再再而三的发生。

三、分析原因

先说两句有用的废话：

1、redis是单线程的，其所有操作都是原子的，不会因为并发产生数据问题；

2、使用高耗时的Redis命令非常危险，会占用唯一线程的大量处理时间，导致其它的请求都处于等待状态。

有上面两句作铺垫，原因就显而易见了！

• 运维人员进行keys *操作，该操作比较耗时，又因为redis是单线程的，所以redis被锁住；
• 此时QPS比较高，又来了几万个对redis的读写请求，因为redis被锁住，所以全部Hang在那；
• 因为太多线程Hang在那，CPU严重飙升，造成redis所在的服务器宕机；
• 所有的线程在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服务卡顿，影响服务使用。