敢在线上做Keys正则匹配操作!你可以离职了

edis开发规范中有一条铁律如下所示

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

然而大家都知道，却一直忘记，所以事故会不断的发生。

下面讲一讲在线上执行正则匹配操作，引起缓存雪崩，最终数据库宕机的原因。

分析原因

OK，先说两句废话

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

2、使用高耗时的Redis命令是很危险的，会占用***的一个线程的大量处理时间，导致所有的请求都被拖慢。(例如时间复杂度为O(N)的KEYS命令，严格禁止在生产环境中使用)

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

• (1)运维人员进行keys *操作，该操作比较耗时，又因为redis是单线程的，所以redis被锁住。
• (2)此时QPS比较高，又来了几万个对redis的读写请求，因为redis被锁住，所以全部Hang在那。
• (3)因为太多线程Hang在那，CPU严重飙升，造成redis所在的服务器宕机
• (4)所有的线程在redis那取不到数据，一瞬间全去数据库取数据，数据库就宕机了。

需要注意的是，同样危险的命令不仅有keys *，还有以下几组

• Flushdb 命令用于清空当前数据库中的所有key
• Flushall 命令用于清空整个 Redis 服务器的数据(删除所有数据库的所有 key )
• CONFIG 客户端连接后可配置服务器

因此，一个合格的redis运维或者开发，应该懂得如何禁用上面的命令。所以我一直觉得出现新闻中那种情况的原因，一般是人员的水平问题。

怎么禁用这些命令呢?

就是在redis.conf中，在SECURITY这一项中，我们新增以下命令：外，对于FLUSHALL命令，需要设置配置文件中appendonly no，否则服务器是无法启动

注意了，上面的这些命令可能有遗漏，大家可以查官方文档。除了Flushdb这类和redis安全隐患有关的命令意外，但凡发现时间复杂度为O(N)的命令，都要慎重，不要在生产上随便使用。例如hgetall、lrange、smembers、zrange、sinter等命令，它们并非不能使用，但这些命令的时间复杂度都为O(N)，使用这些命令需要明确N的值，否则也会出现缓存宕机。

改良建议

业内建议使用scan命令来改良keys和SMEMBERS命令

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!