午夜定时任务如何成为系统杀手？

背景

早上到公司后，查看飞书消息，发现有几条接口超时告警，时间为8点整，遂着手进行排查

排查

机器负载

首先查看了当时时间段的各个机器负载情况，发现基本上所有机器在8点左右CPU均有所上升（包括网关所在的机器），部分机器峰值直接干到了100%，这让我非常吃惊，影响面有点大。

排查方向

目前为止，我们得到两个关键信息：

• 8点整准时开始，持续了大约5分钟
• 大部分机器CPU均有所上涨

好，这说明什么问题呢？

第一，这很有可能是某个服务的某个定时任务引起的，8点对应0时区的0点，大概有服务要进行新一天的逻辑

第二，这很有可能是基础组件导致的，单个服务出问题不足以引起大部分机器都出现这个问题，很可能是这个定时任务所在的服务进行了某些操作，导致基础组件压力过大导致的

我们目前的基础组件有网关、MySQL和Redis等存储

先说网关，网关CPU也有所上涨，但是持续时间对不上，网关机器的持续时间比其他机器长，如果原因在网关，那不可能其他机器只持续了这么短时间，所以排除

后面我去问了下定时任务有关的逻辑，有同事反馈我们有一个限时书币的服务，每日会过期掉要过期的书币，使用MySQL存储，每日0点扫描，然后逐个减去对应用户的账户余额。就是你了。

_ = t.Timer("0 0 0 * * *", logic.xxxx)

原因分析

找到了嫌疑犯，就要分析为什么

现在能解释定时问题了，网关问题也能说通，因为这时候要处理很多用户的账户余额，发送很多请求，网关的压力有点大，CPU上升了

但是我现在还有一个疑问：为什么今天才出现这个告警？

理论上，每日过期的用户数量都差不多的，不会等到今天才爆发

我看了代码，终于发现了问题。

原来是在查询要过期的记录是，使用的是小于等于过期日期，导致时间越长，要查询的数据量就越大，且有没有索引，分批处理时又要不停翻页，导致数据库压力很大

mysql.Table("book_coin").Where("expire_date <= ? and status = 1", expiredDate)

且数据库又是底层组件，很多服务都依赖，所以导致了大部分的机器CPU均上升了

反思

这逻辑修复起来也简单，将小于等于修改为等于就好，为了防止有漏网之鱼，多加了几次定时任务进行巡逻，当然也可以加索引，但是表数据量太大了，加的时间很长且收益不大。

我印象中是做过这个方案的评审的，也对每日过期的逻辑是认可的，但是实现上我没想到是用<=判断的，看来还是要加强组内的CodeReview才行