最近做的企微二开里有个定时任务需求每天早上给销售推日报、每周一推周报、生日当天推祝福、跟进任务到点提醒、客户咨询超时未回提醒。这些都要定时触发发消息。看起来就是写个 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(size10) for task in tasks: if acquire_lock(task.id, ttl300): # 分布式锁 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 让人提心吊胆。