Redis ZPOPMIN 批量取任务后如何避免丢失

我在用 Redis 做延迟任务时，最容易忽略的不是优先级，而是“取出来以后谁负责它”。ZPOPMIN queue:ready 20 会返回最低分成员，并同时把它们从有序集合删除；如果消费者刚拿到任务就进程崩溃，任务既不在待处理集合里，也没有完成记录，结果就是静默丢失。

处理办法是把一次领取拆成可恢复的状态：用 ready 保存待处理任务，用 processing 登记租约，用 done 记录完成，再让成功确认和超时回收都具备幂等性。Redis 官方命令说明可从这里复制：https://redis.io/docs/latest/commands/zpopmin/。

先把 ZPOPMIN 的丢失窗口拆成三类状态

不要直接把业务处理写成“弹出、执行、结束”。更稳妥的模型是：任务 ID 放在 queue:ready 有序集合，任务内容放在 queue:payload 哈希，领取后把 ID 放入 queue:processing，成功后再写入 queue:done。processing 的分数不是业务优先级，而是领取时间，用来判断租约是否过期。

初始化时可以先把状态键和任务内容分开。下面的命令只是数据结构示例，分数 10、20 代表业务优先级，不代表真实执行结果。

# 用任务 ID 作为成员，分数越小越先被取出
ZADD queue:ready 10 task-1001 20 task-1002

# 任务内容单独保存，避免把长参数塞进有序集合成员
HSET queue:payload task-1001 '{"type":"email","to":"user-1001"}'
HSET queue:payload task-1002 '{"type":"email","to":"user-1002"}'

# 仅观察待处理任务，不要用 ZRANGE 后再 ZREM 模拟领取
ZRANGE queue:ready 0 -1 WITHSCORES

用原子领取、确认和超时回收补上崩溃窗口

关键点不在于把 ZPOPMIN 换成另一个命令，而是把“从 ready 弹出”和“登记 processing”放进同一个 Redis 脚本。这样脚本返回给 worker 的每个任务，都已经有处理中记录；worker 随后宕机，回收器仍能找到它。

-- KEYS[1] 是 ready，KEYS[2] 是 processing
-- ARGV[1] 是批量数量，ARGV[2] 是本次领取时间戳
local items = redis.call('ZPOPMIN', KEYS[1], ARGV[1])
for i = 1, #items, 2 do
  -- items 按 member、score 成对返回；这里只登记任务 ID 和租约时间
  redis.call('ZADD', KEYS[2], ARGV[2], items[i])
end
return items

成功确认时，建议用任务 ID 做幂等键：业务侧先保证同一个 ID 不会重复产生不可逆副作用，再删除 processing 并写入 done。确认动作也应尽量放在脚本或事务里，避免只删状态却没有留下完成标记。

# 业务处理成功后再确认；下游写入必须先按 task-1001 做幂等判断
MULTI
ZREM queue:processing task-1001
SADD queue:done task-1001
EXEC

回收器定期找出租约过期的任务，把它们从 processing 放回 ready。这个动作也要保持原子，至少要在同一脚本中先确认任务仍在 processing，再删除旧状态并重新加入 ready。回收后可能出现重复执行，所以不能把“只执行一次”当作 Redis Sorted Set 自动提供的能力。

-- 找出已超过租约的任务，并把仍在 processing 的任务放回 ready
local expired = redis.call('ZRANGEBYSCORE', KEYS[1], '-inf', ARGV[1], 'LIMIT', 0, ARGV[2])
for _, task_id in ipairs(expired) do
  -- 单线程脚本内先删除旧状态，删除成功才允许重新排队
  if redis.call('ZREM', KEYS[1], task_id) == 1 then
    redis.call('ZADD', KEYS[2], ARGV[3], task_id)
  end
end
return expired

别把“没有丢失”误写成“不会重复”

这套设计解决的是崩溃后的可恢复性，语义是至少一次。worker 可能已经调用了外部接口，却在确认前断电；回收器再次投递后，同一任务会执行两次。因此邮件发送、扣库存、写订单等操作要把 task_id 作为幂等键，或在数据库中建立唯一约束。若下游无法幂等，应该把任务结果和业务状态放进同一个可提交边界，而不是继续堆 Redis 命令。

上线后至少观察四组数据：ZCARD queue:ready 表示积压，ZCARD queue:processing 表示在途，SCARD queue:done 表示完成，业务结果表按任务 ID 去重后的数量表示最终落地。processing 长期增长通常是 worker、租约或确认逻辑出了问题；ready 和 done 都不增长而业务结果缺少任务，则要优先查领取脚本和回收器。

# 只读检查四类状态，数字应结合业务总量解释
ZCARD queue:ready
ZCARD queue:processing
SCARD queue:done

# 抽样确认处理中任务确实带有租约分数
ZRANGE queue:processing 0 20 WITHSCORES

常见问题

为什么不先用 ZRANGE 读取，再用 ZREM 删除？

两个命令之间存在并发窗口，多个 worker 可能读到同一成员；即使加锁，也要额外维护锁超时。ZPOPMIN 至少把读取和删除合成了 Redis 内部的一次原子命令，剩下的状态转移再交给 Lua。

processing 的租约时间应该设置多久？

按正常处理时长、网络重试和发布抖动估算，并留出余量。太短会制造重复消费，太长会让真正崩溃的任务恢复很慢，最好结合任务类型设置不同租约。

写入 done 集合后还要保留 payload 吗？

不一定。需要审计或补偿就保留一段时间；只需要去重时可以把完成标记改成带过期时间的键，并确保过期后不会再次产生不可逆副作用。