生产环境禁用 KEYS+DEL，因其会阻塞 Redis 主线程；应使用带游标和分批的 SCAN+DEL Lua 脚本或 Ja va 中通过 RedisConnection 执行 SCAN 迭代删除，避免连接泄漏。

直接使用 KEYS 配合 DEL 来批量删除特定前缀的 Key，听起来很直接，对吧？但在高并发或数据量大的生产环境里，这恰恰是引发服务阻塞的典型操作。真正安全可靠的做法，是采用 Lua 脚本封装 SCAN 和 DEL 命令，既能保证原子性，又不会阻塞主线程服务。

为什么不能直接用 KEYS + DEL

问题的根源在于 KEYS 命令本身。它是一个全库扫描命令，会一次性把所有匹配的 key 加载到内存，并且在这个过程中会锁住 Redis 的主线程。这意味着，在它执行期间，所有的读写请求都只能排队等待。一旦匹配的 key 数量达到几万甚至更多，Redis 很可能卡顿数秒，极端情况下甚至会触发客户端的超时熔断。线上就曾出现过这样的真实事故：有人执行 redis-cli KEYS "user:*" | xargs redis-cli DEL，直接导致依赖 Redis 的订单接口平均延迟飙升到 2 秒以上。

常见的错误现象包括：

• 脚本报错：ERR Error running script (call to f_...): @user_script:1: @user_script: 1: user_script:1: Lua script attempted to access a non-existent key（尤其在集群模式下，脚本内误用 KEYS 会导致此错误）
• 监控指标异常：redis_blocked_clients（被阻塞的客户端数）突然增加，redis_latency_ms（延迟毫秒数）持续高于 100ms。
• 应用层抛出大量 RedisCommandTimeoutException（Redis 命令超时异常）。

EVAL 执行单次 Lua 脚本的隐患

那么，把 KEYS 和 DEL 包进 Lua 脚本里，用一条 EVAL 命令执行，是不是就安全了？比如这种写法：EVAL "return redis.call('del', unpack(redis.call('keys', ARGV[1])))" 0 "cache:*"。看起来很简洁，但遗憾的是，它只是把问题包装了一下。脚本内部依然调用了阻塞式的 KEYS 命令，在 Redis 单线程模型下，其阻塞效应和直接执行 KEYS 没有本质区别。

这种写法还存在几个更具体的问题：

• 不支持 Redis 集群：KEYS 命令无法跨 slot 执行，在集群环境下直接运行就会报错。
• 缺乏分批控制：如果匹配出 50 万个 key，unpack() 函数会尝试一次性将所有 key 传入 DEL 命令，这可能触发 Lua 栈溢出或命令执行超时。
• 没有游标中断机制：一旦执行过程中因网络闪断等原因失败，整个操作会完全中断，无法从断点继续，也无法得知删除了多少。

推荐方案：带游标和分批的 SCAN + DEL Lua 脚本

所以，什么才是正确的姿势？核心思路是用非阻塞的 SCAN 命令替代 KEYS。SCAN 通过游标迭代，每次只取一小批 key（例如 1000 个），然后再分更小的批次调用 DEL。整个过程是增量式的，完全不会阻塞主线程。下面是一个可以直接投入使用的 Lua 脚本示例：

local pattern = ARGV[1]
local count = tonumber(ARGV[2]) or 1000
local batch_size = tonumber(ARGV[3]) or 100
local cursor = "0"
local total = 0

repeat
  local result = redis.call("SCAN", cursor, "MATCH", pattern, "COUNT", count)
  cursor = result[1]
  local keys = result[2]

  if #keys > 0 then
    for i = 1, #keys, batch_size do
      local batch = {}
      for j = i, math.min(i + batch_size - 1, #keys) do
        table.insert(batch, keys[j])
      end
      redis.call("DEL", unpack(batch))
      total = total + #batch
    end
  end
until cursor == "0"

return total

这个脚本的使用方式很灵活：

• 可以通过命令行调用：redis-cli --eval del_by_scan.lua , "user:session:*" 1000 50（注意脚本路径后的逗号分隔）。
• ARGV[1] 是匹配模式，必须包含通配符，例如 "user:session:*"。
• ARGV[2] 控制每次 SCAN 命令返回的 key 数量上限，建议在 100 到 1000 之间。ARGV[3] 控制每批 DEL 操作的 key 数量，建议小于等于 100，以避免单次命令体量过大。
• 该脚本兼容 Redis 4.0 及以上版本，在单机模式和集群模式下均可使用，集群环境下会自动路由到正确的 slot。

Ja va 中用 RedisTemplate 调用 SCAN + DEL 脚本

对于 Spring Boot 项目，同样要避免使用 redisTemplate.keys(pattern) 方法，因为它底层可能使用了阻塞操作。正确的做法是获取原生连接，通过游标进行迭代。

这里有几个关键点需要把握：

• 必须使用 RedisConnection：而不是高级封装的 RedisTemplate，因为后者通常不暴露底层的游标控制能力。
• 合理设置 ScanOptions：ScanOptions.count() 建议设为 100 到 500。设置太小会增加迭代次数，设置太大则可能增加单次网络往返的数据压力。
• 即扫即删，避免堆积：每次迭代拿到一批 key 后，应立即调用 connection.del(key) 进行删除，不要将所有 key 收集到一个大集合中再一次性删除。
• 注意游标资源管理：这是一个容易被忽略但至关重要的细节。务必使用 try-with-resources 语法或显式调用 cursor.close() 来关闭游标，否则会导致连接泄漏。在高频调用场景下，连接池可能因此被快速耗尽。

下面是一个示例代码片段：

redisTemplate.execute((RedisCallback) connection -> {
  long deleted = 0;
  Cursor cursor = connection.scan(
    ScanOptions.scanOptions()
      .match("order:*")
      .count(200)
      .build()
  );
  try {
    while (cursor.hasNext()) {
      byte[] key = cursor.next();
      connection.del(key);
      deleted++;
    }
  } finally {
    cursor.close();
  }
  return deleted;
});

说到底，批量删除操作的安全性，就藏在游标管理和分批处理的细节里。忽略它们，就等于给系统埋下了潜在的稳定性隐患。