可行但仅适用于轻量场景；必须用EVAL执行Lua脚本原子完成“取+删”或“取+标记”，避免LPOP+DEL竞态导致重复消费或消息丢失。
Redis 用 Lua 脚本实现原子性消息获取是可行的，但“简单消息队列”这个目标容易误入歧途——它无法替代专业队列（如 Kafka、RabbitMQ），仅适用于轻量、低吞吐、无严格可靠性要求的场景。关键在于：必须用 EVAL 执行单个 Lua 脚本完成“取+删”或“取+标记”，否则 LPOP + DEL 两步必然存在竞态。
为什么不能直接用 LPOP + DEL？
多个客户端并发执行时，LPOP 返回元素后，该消息仍留在 list 中（只是被取出），若后续处理失败而未及时 DEL 或重试逻辑缺失，就会造成重复消费；更糟的是，另一个客户端可能在你 LPOP 后、DEL 前再次 LPOP 到同一消息。这不是 Redis 的问题，而是应用层没把“获取并确认移除”做成原子操作。
用 Lua 实现原子出队（pop-and-ack）
核心思路：用 EVAL 执行一段 Lua 脚本，从 list 弹出元素，同时记录已处理状态（例如写入一个 set 或用 hash 标记），全部成功才返回消息；任意一步失败（比如 list 为空），就返回 nil。这样调用方拿到非 nil 结果，就代表消息已被“逻辑上独占移除”。
示例脚本（安全出队并记录已消费 ID）：
eval "local msg = redis.call('lpop', KEYS[1]); if not msg then return nil end; redis.call('sadd', KEYS[2], msg); return msg" 2 queue:msgs queue:acked
说明：
-
KEYS[1]是消息列表名（如queue:msgs） -
KEYS[2]是已处理集合名（如queue:acked），用于幂等判断或监控 - 整个操作在 Redis 单线程内完成，天然原子
- 注意：该脚本不处理网络中断或客户端崩溃后的消息恢复——它只保证“取走即视为已接管”，后续需靠业务层超时重试或死信机制兜底
如何避免消息丢失或重复？Lua 本身不解决，但能帮你建边界
Lua 脚本不能自动重试、不能持久化消费上下文、也不提供 ACK 确认回执机制。它只划清一条线：在 Redis 内，“取出并登记”是一次不可拆分的动作。真正防丢防重得靠组合策略：
- 消费者拿到消息后，必须尽快处理并主动调用另一个 Lua 脚本做“最终确认”（比如从
queue:acked移到queue:done），或超时后允许其他节点抢占 - 不要依赖
BLPOP配合 Lua——BLPOP会阻塞，而EVAL不支持阻塞命令，所以原子出队只能是非阻塞的；需要等待时，得靠客户端轮询或结合PUBLISH/SUBSCRIBE - 如果消息体较大（>10KB），频繁
LPOP+ Lua 序列化开销明显，此时应考虑用Stream类型（XREADGROUP）而非 list + Lua
最常被忽略的一点：Lua 脚本里的 redis.call() 抛异常会导致整个 EVAL 失败回滚，但 redis.pcall() 不会——如果你在脚本里做了条件分支并依赖中间结果，务必统一用 redis.call()，否则部分命令成功、部分失败的状态会让队列进入不可预期的中间态。
