Golang 实现基于 Redis 的延时任务队列
基于Redis的ZSET实现延时队列需解决并发重复消费、失败重试混乱、精度不足及内存爆炸等问题。通过Lua脚本保证取删原子性,使用毫秒级时间戳,对临时错误采用指数退避重试,永久错误记入独立哈希表,并限制最大延迟、定期清理过期任务、使用紧凑序列化格式。
延时队列这事,多少有点“一看就会,一写就废”的意思。用 Redis 的 ZSET 来做,思路确实很直白——把时间戳塞进 score,到期了用 zrangebyscore 一拉,完事。但真正干过的人都知道,这里面的坑,远不是 ZADD 一个命令能填平的。
从并发重复消费,到失败重试乱成一锅粥;从精度不够导致任务“撞车”,到内存被打爆——每一个都够你头疼一阵子的。所以,今天这篇东西,就是把这些实际落地里会踩的坑,一个个掰开揉碎了说清楚,顺带给出经过验证的解法。

为什么不用 zadd 直接塞时间戳当 score 就完事?
乍一看,逻辑确实通顺。但问题在于,“取”和“删”不是原子操作。zrangebyscore 返回的只是一个快照,多个 worker 同时拉同一段区间,必然重复消费。更致命的是,如果任务执行失败,你把它放回去时,原 score 可能已经过期了,重设时稍有不慎就盖了别的逻辑。
所以,真正靠谱的做法,核心就几条:
- 用 zremrangebyscore 搭配 zrange,实现“查删分离”。前者原子性地摘走一批到期任务(返回被删的元素),后者再去看你摘的是什么(前提是把任务序列化塞进 value)
- 或者直接上 Lua 脚本,把整个“取、删、返回”流程包在里面,中间状态不对外暴露
- score 必须用毫秒时间戳,比如 time.Now().UnixMilli()。用秒级的话,同一秒内的多个任务会因 score 相同而排序失控
怎么让 Go worker 安全轮询且不空转?
千万别写死循环加固定 Sleep,那既浪费连接又压 Redis。核心思路是:每次 zrangebyscore 带上 WITHSCORES,检查结果是否为空;为空就休眠,但休眠时间得动态调整。
具体做法是这样的:
- 用 redis.Client.ZRangeByScoreWithScores 方法,传入 &redis.ZRangeBy{Min: "-inf", Max: fmt.Sprintf("%d", time.Now().UnixMilli())}
- 每次轮询前加 context.WithTimeout(ctx, 3*time.Second),防止单次命令卡死
- 连接一定要复用,用 redis.NewClient() 初始化一次就行,别在 for 循环里反复 defer conn.Close()
- 首次启动时可以预热:用 ZCARD 看一眼队列长度,大于 0 就立刻触发一轮拉取,避免首屏延迟
任务执行失败后如何可靠重试?
直接把失败任务 zadd 回原队列,风险极高。如果原因是下游雪崩,重插只会火上浇油;如果是参数错误,那就成了无限循环报错。必须区分失败类型,并控制重试节奏。
这里有几个实操建议:
- 对于临时性错误(网络超时、HTTP 503 等),用指数退避重插:第 1 次失败后 score = now + 1000(1 秒后),第 2 次 + 2000,第 3 次 + 4000……上限设为 5 分钟
- 对于永久性错误(比如 JSON 解析失败、必填字段为空),记录到独立的 failed_tasks: Hash 表,带错误堆栈和原始 payload,留给人工去处理
- 所有重插操作必须用 Lua 脚本保证原子性:先 HGET 查重试次数,再 ZADD,再 HINCRBY,三步不可拆
- 任务结构体里显式加一个 RetryCount int 字段,序列化进 Redis 的数据必须自包含,别依赖外部计数器
怎么防止任务堆积导致内存爆炸?
Redis 内存不是无限的,而延时队列天然会积压未到期任务。如果业务方一口气投递一堆 7 天后执行的任务,又没有监控,几小时就能把实例打爆。
所以,得从几个层面下手:
- 投递端强制校验:if delay > 7*24*time.Hour { return errors.New("max delay is 7 days") }
- 定期用 ZCOUNT key (now + 3600) +inf 统计远期任务量,告警阈值设到 10 万条
- 后台启一个 goroutine,每 5 分钟执行一次 ZREMRANGEBYSCORE key -inf (now - 300000),清理那些已过期超过 5 分钟仍然无人处理的任务(说明已经丢了)
- 所有任务的 value 必须用紧凑格式:优先选 gob 或 msgpack,别用 JSON——同样结构体,JSON 要多出 30% 到 50% 的体积
说一千道一万,实现本身不算太难,真正麻烦的是那些边界条件。比如系统时间回拨,一下让大量任务瞬间“到期”;或者 Redis 主从切换期间,ZSET 命令部分丢失。这些问题靠代码很难完全兜住,最终还是得依赖运维侧的时钟同步策略和哨兵配置来兜底。
Windows 10 是一款微软推出的经典操作系统,拥有硬件兼容性与多任务处理能力。它更偏向把系统状态查看和常用调节动作放在一起,适合需要持续观察和微调设备状态的场景。
极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。
















