正常逻辑：在关注公众号后，用关注时间+延后时间来进行定时任务执行推送，在特定的时间段推送特定的消息给微信用户，每个access token的用户同一条消息只会接收到一次。
Bug表象：有一部分微信用户接到了重复的消息推送，比如关注后2小时的推送任务是“你好”，连续收到多条“你好”。造成了极大的用户不良体验，但是QA同学和自测试环境怎么都无法复现这个Bug，无从下手排查。
使用技术：Node.js的egg.js框架 + Linux的CronTab定时器任务 + Mysql数据库 + 微信公众号开发工具
排查原因：
在执行发送任务时将文案等数据拼装好交由微信那边的接口发送到用户的微信，再获取哪些定时任务需要执行时候，是30秒轮询一次看执行时间execute_time是否到了，到了的话就拿出来放入队列中等待执行，执行完毕再修改数据库定时任务状态为已执行。
（1）由于node是单线程，在用户量到三四万这个瓶颈的时候，就会容易出现这个Bug，因为它单线程执行，30秒要推那么多条消息显然是不可能的，于是30秒还没推送完全部，下一次30秒轮询又到了，又把没执行的定时任务拿出来转圈圈等待发送，于是同一个用户的同一个定时任务推送越堆积越多，导致最后推送N条重复的。
（2）我们进行的不是简单的推送，还要查订单，查课程信息，查老师联系方式，查优化方案，查上课时间，查…一堆一堆的数据拼接成的动态文案素材，在单线程环境下，虽然做了async , await 异步处理，但是主线程还是要根据子IO线程返回值拼接，所以非常占用时间。
（3）在调用微信公众号接口的时候，如果在30秒内微信用户那边没有接收到消息的响应（网络原因或者飞行模式或者在山上海里之类的），微信的接口会在30秒后进行重试机制，也就是再推一次，一共重试三次。
解决方案：
（1）延长轮询时间，将原来的30秒改为了三分钟，但是这个很明显治标不治本，用户量再多的话也是执行不完。
（2）新增数据库执行状态为“正在执行中”，一拿出该条用户推送任务后就马上修改状态，而不是等推送完再修改，拿的时候不再拿这个状态的定时任务。
（3）优化我们这边获取复杂数据的逻辑，优化SQL，将调用微信接口发送的那一步操作任务改为异步执行，不加await回调，反正也不需要它的什么返回值。