Redis线上做Keys命令引发的生产事故

本文深入剖析了一起因不当使用Redis命令导致的系统事故,详细解读了事故原因,包括工程师执行高耗时的keys*命令,引发Redis锁死及后续的数据库雪崩。文章强调了Redis开发规范,提出使用scan命令代替keys*,并提供了禁用危险命令的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

导火索:线上频发报警,网关频繁转发超时,系统很多服务响应时间过长,服务cpu过载,数据库死锁等不正常现象

问题排查:目标范围缩小在近两日上线功能,并锁定在新上线的操作redis缓存功能上。

问题复现:将功能在开发环境测试,由于访问量不足并未发现异常。

将某需求下线后,线上环境得以好转。

分析代码:发现如下

    /**
     * Del.
     *
     * @param keys the keys
     */
    public static void del(String... keys) {
        try (Jedis jedis = getJedis()) {
            jedis.del(Arrays.stream(keys).map(v -> key(v)).collect(Collectors.toList()).toArray(new String[]{}));
        } catch (Exception e) {
            log.error("Redis error:{}", ExceptionTools.getExceptionStackTrace(e));
            throw new RuntimeException(e);
        }

    }

    /**
     * del by pattern
     *
     * @param pattern prefix*
     */
    public static Long del(String pattern) {
        try (Jedis jedis = getJedis()) {
            Set<String> keys = jedis.keys(key(pattern));
            if (CollectionUtils.isNotEmpty(keys)) {
                return jedis.del(keys.toArray(new String[0]));
            } else {
                return 0L;
            }
        } catch (Exception e) {
            log.error("Redis error:{}", ExceptionTools.getExceptionStackTrace(e));
            throw new RuntimeException(e);
        }
    }

事故原因工程师执行redis keys * 导致环境濒临宕机
由于及时发现,虽然未造成重大事故,但实属本年度PO级特大事故:
 

由于工程师直接操作上线redis,执行:

keys * wxdb(此处省略)cf8*

新增的单参数的del方法覆盖了多参数的del方法,所有调用del的地方都走单参del方法,然而此方法内含有keys命令。

redis是单线程服务,这样的命令,导致redis锁住,导致CPU飙升,引起所有支付链路卡住,等十几秒结束后,所有的请求流量全部挤压到了rds数据库中,使数据库产生了雪崩效应,发生了数据库宕机事件。

由于之前验收环境缓存量小,未发现此影响其他服务响应延迟的问题。

运维表示之后会逐步收回运维部各项权限!

二、一条铁律

在业内,redis开发规范中有一条铁律如下所示:

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

然而大家都知道,却一直忘记,所以事故会不断的发生。
下面讲一讲在线上执行正则匹配操作,引起缓存雪崩,最终数据库宕机的原因。

三、深度分析

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

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

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

  • 运维人员进行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服务卡顿,影响服务使用。

 

### 使用 Redis 命令进行模糊匹配删除 KeysRedis 中直接通过 `DEL` 或者 `UNLINK` 命令配合通配符来实现批量删除特定模式的键并不是一种推荐的法,因为这可能会导致性能问题。然而,在某些情况下确实可以通过组合其他命令间接达成目的。 对于想要基于 Glob 风格模式(例如 `*`, `?`, `[...]`)删除多个 key 的场景,通常建议先利用 `SCAN` 命令遍历数据库中的所有 keys 并筛选符合条件的目标集合,再针对这些目标调用 `DEL` 或 `UNLINK` 来移除它们[^1]。 下面是一个 Python 脚本的例子,展示了如何安全有效地完成这一操作: ```python import redis def delete_keys_by_pattern(pattern='*', host='localhost', port=6379, password=None): client = redis.StrictRedis(host=host, port=port, decode_responses=True, password=password) cursor = '0' while cursor != 0: cursor, keys = client.scan(cursor=cursor, match=pattern, count=100) if keys: client.delete(*keys) delete_keys_by_pattern('my-prefix-*') ``` 此脚本会连接到指定地址和端口上的 Redis 实例,并根据给定的模式参数扫描并删除相应的 keys。注意这里使用了 `scan` 方法而不是简单的 `KEYS`,前者可以在不影响服务的情况下逐步检索数据,从而避免阻塞整个服务器进程。 另外需要注意的是当涉及到生产环境下的大规模清理工作时应当格外小心谨慎,最好提前好充分测试以及备份措施以防意外发生。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值