如果你看不到完整的标题，别气馁，试试将光标移到它上方！
2023年8月29日 来源：脚本之家
文 | 风筝
来源 | 古时的风筝（ID：gushidefengzheng)
如若转载请联系原公众号
前两天跟朋友讨论技术，他说他们的服务器从凌晨零点开始，就开始跑各种各样的定时任务，基本上能跑到早晨5、6点钟。因为他们的业务属于访问量不大，但是数据量非常大，而且每天的数据要根据一些规则重新计算，所以就每天这么跑着。一到夜里，服务器负载比白天还高。
如果服务器上有灯光根据负载高低进行闪烁，那到了夜里，一定会看到他们的服务器唰唰的闪着金光。
说到这儿，我想到了之前的一件事儿。
有一天上午到公司不久，运维的同事悠悠的走过来，苦笑着说：“你们的代码凌晨两点在干什么，服务器都差点搞挂了”。
原来是因为一个定时任务（也是计算型的任务）开的线程太多了，之前由于计算量比较少，很快就结束了。那天由于业务调整，数据量一下子大了很多，线程又开的过多了，导致长时间负载过高，直接就给运维发了预警通知了。应用服务器还好，数据库服务器差点没顶住。
由于这些数据计算的时间长一点、短一点都没关系，所以后来把线程数减少了一些。
有一些场景是可以把定时任务放到凌晨来执行的。
夜里有一个特点，大多数的应用在夜里的流量都会比较低，也就是服务器的资源比较空闲，这个时候，正好可以将资源利用起来，执行一些逻辑。
而执行的这些逻辑有一个核心特点，那就是可以放到晚上执行，实时性要求不是很高的业务可以。
这个功能很常见了，不管是电商应用、社交应用等等，凡事有用户用的系统，将来一定会涉及到报表的场景。报表一般都包括对数据的总览，要出一张报表，可能会涉及到多张表，甚至多个数据库，关联的数据更是百万、千万，甚至上亿条。
那这样一来呢，如果是放在后台，用户到界面上进行实时生成的话，不仅老板不满意，测试同事还会给你提bug，说你的接口太慢了。
对于报表来说，看前一天的数据就足够了，没必要看到今天的数据， 所以放在夜里跑任务完全没问题，这时候你一条 SQL 执行1分钟、2分钟也没关系，只要不是太离谱就可以了。
就像我那个朋友公司一样，他们的业务会涉及到大量的数据处理的工作，包括前期的数据处理，以及每天的重新计算，而且数据量很大。
这些清洗和计算也没有那么高的实时性，只要在当天跑完就可以了。但是如果你放到白天运行，就会影响到线上业务。要不然就得多弄几台单独的服务器跑，这样成本就上来了。
所以这样的场景，也可以放到夜里跑。
数据库备份、文件备份以及数据同步等任务可以在凌晨执行，这就很常识了。
有些业务，可能在正常运行的时候发生了异常，当然不能是主业务。一些旁路任务发生了异常，这时候，系统一般会写一条日志，记录异常发生的上下文，越详细越好，用于事后分析以及补偿操作。
等到夜里的时候，检查这种异常业务，根据异常发生时记录的上下文信息，进行二次处理。当然不能是发短信、发通知这种功能了，如果夜里给用户发短信，免不了要被投诉。
几乎每一个系统都会有夜里执行的任务，这些任务的特点：
你们的代码在凌晨两点在干什么呢？
