最近做的企微二开里有个定时任务需求:每天早上给销售推日报、每周一推周报、生日当天推祝福、跟进任务到点提醒、客户咨询超时未回提醒。这些都要定时触发发消息。看起来就是写个 cron,做完发现定时任务的可靠性比业务逻辑还重。把踩过的坑记下来。
底层用的是Eyun 平台开放的企微 API,承接消息发送,本文重点不在调接口,在"定时任务怎么可靠调度和发送"。
定时任务不是简单 cron
最早用系统 cron 跑,两天翻车:
服务部署多实例,cron 在每个实例都跑,消息发 N 遍
cron 任务卡住,后续任务全堵
任务失败没重试,员工当天没收到日报
凌晨任务集中在 0 点,瞬间并发打爆消息接口
定时任务要解决:单实例执行、失败重试、错峰执行、幂等保证。系统 cron 搞不定。
任务调度引擎
自建轻量调度引擎,不用 Quartz 那么重。核心表:
scheduled_task 表: id task_type daily_report / birthday / follow_up target_uin 接收人 cron_expr "0 9 * * *" # 每天9点 next_run 下次执行时间 status pending / running / done / failed last_run retry_count payload 任务参数(JSON)调度器常驻进程,每秒扫表找next_run <= now AND status = pending的任务,抢锁执行:
def scheduler_loop(): while True: tasks = task_store.fetch_due(size=10) for task in tasks: if acquire_lock(task.id, ttl=300): # 分布式锁 try: execute(task) task.status = "done" except Exception: task.retry_count += 1 if task.retry_count < 3: task.next_run = now() + 60 else: task.status = "failed" finally: release_lock(task.id) task.next_run = calc_next(task.cron_expr)分布式锁保证多实例只有一个执行同一任务。锁 TTL 防止执行卡死锁不释放。
错峰执行:别都挤在整点
定时任务集中在整点(9:00、0:00)会瞬间高并发。错峰策略:
随机偏移:9 点的任务加随机 0-5 分钟偏移,9:00-9:05 分散
按接收人 hash 分批:同 9 点的 1000 个任务,按 uin hash 分 10 批,每批隔 1 分钟
限流:消息发送接口加令牌桶,控制每秒并发
不做错峰,9 点一到 1000 条日报同时发,企微接口限流直接拒一部分,员工收不到。关于消息发送和任务管理接口,可以看Eyun 开发文档。
任务幂等:重复执行不发重复消息
任务可能重试、可能多实例抢锁后都执行。幂等保证不重复发消息:
幂等键:
task_id + run_date,发消息前查是否已发发消息和标记完成在一个事务里
重试时查幂等表,已发的跳过
不做幂等,日报发两遍,员工觉得系统出 bug 了,信任度下降。
失败重试和补偿
任务失败要重试,但不能无限重试:
即时重试:3 次,间隔 1 分钟、5 分钟、15 分钟
最终失败:标记 failed,推告警给运维
补偿机制:当天日报没发成,第二天补发"昨日日报"
补偿比单纯重试更人性化——员工没收到今天的,至少明天能看到昨天的。不做补偿,任务失败就丢了,员工什么都不知道。
时效保证:准时发送
有些任务对时效敏感——生日祝福要在当天早上发,不能延迟到下午。时效保证:
优先级队列:高时效任务插队
超时检测:任务执行超 N 分钟没完成,告警
容量预留:高峰期预留并发数给高时效任务
不保证时效,生日祝福下午才发,员工觉得敷衍。这种体验问题不大但很伤好感。
可观测性
定时任务上线后要能看到:
今日待执行 / 已完成 / 失败数
每类任务的平均执行时长
失败任务清单和失败原因
消息发送成功率
一个简单的运维后台展示这些数据。没有可观测性,任务没发出去都不知道,等员工投诉才发现。
写在最后
定时任务这套东西,难点不在 cron 表达式多准,在分布式锁、错峰执行、幂等保证、失败重试、时效保证、可观测性这些工程细节。每一项都不深奥,但少做一项任务就重复发或者漏发。这套搭扎实,定时消息真能准时、准确、不重复地发到员工手里——而不是时不时出 bug 让人提心吊胆。