Redis Lua脚本不能关闭进程，仅能原子操作状态；优雅停任务需协调机制+Lua封装关键判断+外部信号配合，如设shutdown_flag、清理队列、保存checkpoint，最终由worker自行退出。
Redis Lua 脚本本身不能“关闭分布式任务”，它只是原子执行逻辑的工具；真正要优雅停任务，得靠你设计的协调机制 + Lua 脚本封装关键判断 + 外部控制信号配合。直接用 EVAL 执行 SHUTDOWN 或杀进程是危险且无效的——Lua 运行在 Redis 服务端上下文，无权终止进程或集群。
为什么不能在 Lua 脚本里调用 shutdown？
Redis 的 Lua 环境被严格沙箱化：redis.call() 只允许调用 Redis 命令列表里的指令，而 SHUTDOWN 不在其中（它是 redis-cli 或 TCP 协议层的管理命令）。尝试执行会报错：(error) ERR unknown command 'shutdown'。更关键的是，即使绕过限制，从一个节点内部关掉自己，也会导致集群脑裂、数据不一致或客户端连接中断。
-
SHUTDOWN必须由外部客户端（如 redis-cli、运维脚本）发起，且需逐节点操作 - Lua 脚本能做的，是协助“任务级”优雅退出：比如清空待处理队列、标记 worker 为 offline、释放锁、保存 checkpoint
- 把“关任务”和“关 Redis 进程”混为一谈，是常见误解起点
用 Lua 脚本实现任务状态协同退出
典型场景：多个 worker 从 task:queue 拉取任务，你希望发一个信号，让所有活跃 worker 处理完当前任务后不再取新任务，并自动退出。Lua 脚本在这里负责原子更新状态 + 防止竞态。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 定义一个全局开关键：
task:shutdown_flag，值为0（运行中）或1（准备退出） - worker 启动时读取该键，循环中每次取任务前都
GET task:shutdown_flag，若为1则跳过拉取，进入 cleanup 流程 - 触发退出时，用 Lua 脚本原子设置开关并清理残留：
eval "redis.call('SET', 'task:shutdown_flag', '1') redis.call('DEL', 'task:in_progress:' .. ARGV[1]) redis.call('ZREM', 'task:scheduled', ARGV[2]) return 1" 0 worker-001 task-20260713
- 这样避免了多个 worker 同时读到旧值、同时决定退出、又同时删同一 key 的 race condition
- 脚本里不包含业务逻辑（如写 DB、发消息），只做 Redis 状态变更——这是 Lua 安全边界
配合外部信号完成真正的“优雅收尾”
Lua 脚本管状态，但最终进程退出必须由 worker 自己控制。你需要一个轻量协调层：
- worker 进程监听 Unix signal（如
SIGUSR2）或轮询task:shutdown_flag - 一旦检测到退出信号，停止消费新任务，等待当前任务
EXEC完成（可用WATCH+MULTI/EXEC保证事务性） - 用 Lua 脚本提交 final checkpoint：
eval "redis.call('HSET', 'task:checkpoint', KEYS[1], ARGV[1])" 1 last_processed_id 12345 - 最后调用
os.exit(0)或process.exit(0)—— 这步永远不在 Lua 里做 - 集群维度关闭仍需外部脚本：逐节点执行
redis-cli -h $host -p $port shutdown save，确保 RDB/AOF 写完
最容易被忽略的点：Lua 脚本再“优雅”，也救不了没设计好退出协议的 worker。状态同步、超时兜底、checkpoint 一致性、以及 shutdown_flag 的 TTL（防残留），这些才是决定是否真优雅的关键。脚本只是其中一环，不是银弹。
