使用 EVAL、SCAN 和 DEL 的 Redis 通配符删除脚本返回“非确定性命令后不允许写入命令”

因此，我正在寻求构建一个 lua 脚本，该脚本使用 SCAN 根据模式查找键并删除它们（原子地）。我首先准备了以下脚本

local keys = {};
local done = false;
local cursor = "0"
repeat
    local result = redis.call("SCAN", cursor, "match", ARGV[1], "count", ARGV[2])
    cursor = result[1];
    keys = result[2];
    for i, key in ipairs(keys) do
        redis.call("DEL", key);
    end
    if cursor == "0" then
        done = true;
    end
until done
return true;

这会吐出以下“错误：@user_script：9：在非确定性命令后不允许写入命令”所以我想了一下并想出了以下脚本：

local all_keys = {};
local keys = {};
local done = false;
local cursor = "0"
repeat
    local result = redis.call("SCAN", cursor, "match", ARGV[1], "count", ARGV[2])
    cursor = result[1];
    keys = result[2];
    for i, key in ipairs(keys) do
        all_keys[#all_keys+1] = key;
    end
    if cursor == "0" then
        done = true;
    end
until done
for i, key in ipairs(all_keys) do
    redis.call("DEL", key);
end
return true;

仍然返回相同的错误（@user_script：17：在非确定性命令之后不允许写入命令）。这让我难住了。有什么办法可以规避这个问题吗？

脚本是使用 phpredis 和以下内容运行的

$args_arr = [
          0 => 'test*',   //pattern
          1 => 100,     //count for SCAN
  ];
  var_dump($redis->eval($script, $args_arr, 0));

UPDATE:以下内容适用于 Redis 3.2 及以下版本。从该版本开始，基于效果的复制解除了对非决定论的禁令，因此所有的赌注都将被取消（或者更确切地说，将被取消）。

你不能（也不应该）混合SCAN命令族与脚本中的任何写入命令都是如此，因为前者的回复取决于内部 Redis 数据结构，而这些数据结构又对于服务器进程来说是唯一的。换句话说，两个 Redis 进程（例如主进程和从属进程）不能保证返回相同的回复（因此在 Redis 复制上下文中[这不是操作，而是基于语句]，这会破坏它）。

Redis 尝试通过阻止任何写入命令（例如DEL）如果它是在随机命令之后执行的（例如SCAN但是也TIME, SRANDMEMBER和类似）。我确信有办法解决这个问题，但是你想这样做吗？请记住，您将进入未知领域，其中系统的行为未定义。

相反，接受这样一个事实：您不应该混合随机读取和写入，并尝试考虑一种不同的方法来解决您的问题，即根据模式以原子方式删除一堆键。

首先问问自己是否可以放宽任何要求。它必须是原子的吗？原子性意味着 Redis 在删除期间将被阻塞（无论最终实现如何），并且操作的长度取决于作业的大小（即被删除的键的数量及其内容[删除一个大集合是例如，比删除短字符串更昂贵]）。

如果原子性不是必须的，则定期/惰性地SCAN并小批量删除。如果这是必须的，请理​​解您基本上是在尝试模仿evil KEYS命令 :) 但如果您事先了解该模式，您可以做得更好。

假设该模式在应用程序运行时已知，您可以收集相关键（例如在集合中），然后使用该集合以原子和复制安全的方式实现删除，这比遍历整个键空间更有效。

然而，最“困难”的问题是，如果您需要在确保原子性的同时运行临时模式匹配。如果是这样，问题归结为获取键空间的按模式过滤快照，然后立即进行一系列删除（再次强调：当数据库被阻止时）。在这种情况下你可以很好地使用KEYS在你的 Lua 脚本中并希望得到最好的结果......（但充分了解你可能会求助于SHUTDOWN NOSAVE很快:P)。

最后的优化是对键空间本身进行索引。两个都SCAN and KEYS基本上都是全表扫描，那么如果我们对该表建立索引呢？想象一下，在事务期间可以查询的键名称上保留索引 - 您可能可以使用排序集和字典范围（HT@TwBert）消除了大部分模式匹配需求。但代价高昂……您不仅需要进行双重簿记（将每个密钥的名称成本存储在 RAM 和 CPU 中），而且还被迫增加应用程序的复杂性。为什么要增加复杂性？因为要实现这样的索引，您必须自己在应用程序层（可能还包括所有其他 Lua 脚本）中维护它，小心地将每个对 Redis 的写入操作包装在一个事务中，该事务也会更新索引。

假设您完成了所有这些（并考虑到明显的陷阱，例如增加的复杂性可能导致错误、Redis、RAM 和 CPU 上的写入负载至少加倍、扩展限制等等......）您可以拍拍自己庆幸自己以一种不符合 Redis 设计初衷的方式使用了 Redis。虽然即将推出的 Redis 版本可能（或可能不）包含针对这一挑战的更好解决方案（@TwBert - 想要联合 RCP/contrib 并再次破解 Redis 吗？），在尝试此操作之前，我强烈建议您重新考虑最初的要求并验证您是否正确使用 Redis（即根据您的数据访问需求设计您的“架构”）。