不能直接用lpush+brpop做优先级队列，因其仅支持fifo，无法跳过低优先级任务；多list轮询有竞态且非原子；正确做法是zset+lua实现原子取最高优任务。
为什么不能直接用 LPUSH + BRPOP 做优先级队列
Redis 原生命令不支持按 score 优先级阻塞弹出。你用 LPUSH 把高优先级任务插到队头，低优先级插到队尾，看似有序，但多个 worker 并发 BRPOP 时，顺序完全不可控——网络延迟、客户端重试、连接抖动都会打乱执行次序。更糟的是，一旦某个 worker 在处理中崩溃，对应任务就永久丢失，没有重入保障。
真正可行的方案是组合使用：ZSET 存任务（用 score 表示优先级，越小越先执行），HASH 存任务详情，再配合 EVAL 原子脚本实现「取任务 + 标记为 processing」两步不中断。
-
ZSET的score推荐用int64时间戳反序（如math.MaxInt64 - time.Now().UnixMilli()），避免浮点精度问题和负数排序陷阱 - 不要把完整任务结构体 JSON 序列化后塞进
ZSET成员（member）字段——Redis 对 member 长度有限制（512MB 理论值，实际超 10KB 就影响性能），应只存唯一task_id - worker 启动时必须设置合理的
socket timeout（建议 ≥ 30s），否则BRPOP超时会导致任务被其他 worker 重复争抢
如何用 Lua 脚本原子性地「抢占并锁定」最高优先级任务
核心逻辑：从 ZSET 取出 score 最小（即优先级最高）的 task_id，同时把它从 ZSET 移除，并写入一个临时 processing HASH，附带过期时间（防止 worker 挂掉后任务卡死）。这个三步操作必须原子执行，否则会引发竞态。
下面是一个生产可用的 Lua 脚本（通过 redis.Eval 调用）：
local task_id = redis.call('zpopmin', KEYS[1], 1)
if #task_id == 0 then
return nil
end
local now = tonumber(ARGV[1])
local ttl = tonumber(ARGV[2])
redis.call('hset', KEYS[2], task_id[1], ARGV[3])
redis.call('expire', KEYS[2], ttl)
return task_id[1]
Go 中调用示例：
script := redis.NewScript(luaScript)
taskID, err := script.Do(ctx, rdb, []string{"queue:zset", "queue:processing"},
time.Now().UnixMilli(), 300, payloadJSON).Text()
if err == redis.Nil {
// 队列空
} else if err != nil {
// 脚本执行失败（如 key 不存在、语法错）
}
-
zpopmin是 Redis 5.0+ 才支持，低于此版本需改用zrange+zrem组合，但必须包裹在EVAL里保证原子性 -
ARGV[3]是任务载荷（如 JSON 字符串），它不参与排序，只用于后续从HASH中读取完整数据 - 别省略
expire—— 如果 worker 处理完没主动删queue:processing中的 key，靠 TTL 自动清理是最后防线
Go worker 如何安全地完成任务并触发重试逻辑
任务执行成功后，要从 queue:processing 中删除对应 task_id；失败时则需根据错误类型决定是否放回队列。关键点在于：**不能简单 ZADD 回原 ZSET，必须调整 score 延迟重试**。
- 非瞬时错误（如数据库连不上、HTTP 503）建议指数退避：
newScore = now + int64(math.Pow(2, float64(attempt)) * 1000) - 对已重试超过 3 次的任务，应写入独立的
queue:failedLIST并告警，避免无限循环拖垮 Redis - 使用
redis.Watch监控queue:processing的变更，确保「读取任务详情 → 执行 → 删除」这三步不被其他协程干扰（尤其当同一 task_id 被多个 worker 锁定时） - 务必在
defer中设置 panic 捕获，否则 goroutine 崩溃会导致任务锁永远不释放
为什么推荐用 github.com/go-redis/redis/v9 而不是 redigo
redigo 的连接池模型对 pipeline 和事务支持较弱，且无内置 context 传递能力，在超时控制和链路追踪上容易失控。而 redis/v9 原生支持 context.Context，所有命令可被 cancel，这对分布式队列至关重要——比如 worker 收到 shutdown 信号时，正在执行的 BRPOP 必须立刻退出，而不是等 30s 超时。
-
redis/v9的ClusterClient能自动路由ZSET命令到正确 slot，而redigo需手动做 key hash 计算 -
redis/v9的Script.Load+Script.Eval接口更贴近 Lua 脚本语义，参数类型检查严格，减少运行时WRONGTYPE错误 - 它的
Ring模式对多节点优先级队列分片友好，比如按业务域前缀分片：queue:order:zset和queue:notify:zset可部署在不同物理节点
最易被忽略的是连接泄漏：用 redigo 时若忘记 conn.Close() 或 pool.Put()，短连接模式下会快速耗尽文件描述符；而 redis/v9 的 UniversalClient 内部连接池由 GC 友好管理，只要 client 不被长期 hold 住，基本不会漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
