Redis中Lua递归调用是否违规？集群环境是否可行？

一、是否违反程序化键生成规则？ #

结论是没有违反。Redis程序化键生成规则的核心要求是：脚本不能在运行时动态生成键名，所有操作的键必须提前通过KEYS参数传入。

• 外层脚本：仅通过KEYS[1]获取指定键foo的值，未动态生成任何键；调用EVALSHA时，将GET foo的结果作为内层脚本的KEYS[1]传入，属于参数传递行为，而非内层脚本自行生成键。
• 内层脚本：直接使用传入的KEYS[1]执行SET操作，完全符合规则，无动态生成键的逻辑。

二、集群与非集群环境的运行问题 #

非集群环境（单实例/主从架构） #

无运行问题，非集群环境不强制键的哈希槽约束，嵌套脚本的调用逻辑可以正常执行。

集群环境 #

会触发严重的跨槽错误，原因如下：

• Redis集群会根据外层脚本KEYS[1]（即foo）的哈希槽，将整个外层脚本路由到对应节点。
• 内层脚本的KEYS[1]是GET foo的结果（假设为某键baz），baz的哈希槽大概率与foo不在同一节点。而Redis集群要求单个脚本必须在同一节点执行，不允许跨节点操作，因此内层脚本的SET操作会直接抛出CROSSSLOT Keys in request don't hash to the same slot错误。
• 额外风险：若目标节点未缓存内层脚本的SHA哈希值，还会触发NOSCRIPT错误，需额外处理脚本重试逻辑。

三、其他潜在问题 #

• 原子性断裂风险：外层脚本中GET foo与内层脚本SET操作并非原子绑定，若两次操作之间有其他客户端修改foo的值，会导致内层脚本使用错误的键执行操作。
• 调试维护成本高：嵌套脚本逻辑层级深，错误信息会被外层脚本包裹，出现问题时难以快速定位根源。
• 脚本缓存依赖问题：内层脚本依赖目标节点已缓存对应的SHA哈希值，若节点重启或脚本被淘汰，需重新传入完整脚本，增加了逻辑复杂度。

内容的提问来源于stack exchange，提问作者Lau