请教个定时任务处理问题

2022-01-25 14:44:55 +08:00
 brader

有批晚上跑的定时任务,比如有几十万条数据要处理,那么这段时间 mysql 的查询和更新就比较频繁,直接是硬件有多快跑多快,在资源监控界面,就会看到持续一小段时间资源快跑满了。

请教下各位这种情况是怎么处理的?

1:不用管他,这是正常的。

2:每条记录处理完,加个 sleep 间隔暂停一下?

3:其他更好的方法?

2406 次点击
所在节点    程序员
23 条回复
RRRoger
2022-01-25 14:49:13 +08:00
用队列呀
justest123
2022-01-25 14:52:24 +08:00
好奇,性能拉满会危害服务器的身体健康?
brader
2022-01-25 14:55:53 +08:00
@justest123 是这样的,阿里云有个短信提醒,领导老是收到类似,xx 实例 cpu 使用率 100%超过 1 分钟,这样的短信提醒,就老是问我是不是有问题。。。
brader
2022-01-25 14:57:21 +08:00
@RRRoger 数据都是在表里的,到点了就处理,用不用队列,最终还是要落到数据表的,感觉这个场景,用队列和加个 sleep 间隔一下差不多?
Gota
2022-01-25 15:05:39 +08:00
有可能处理的时候并发数开高了? 一般单线程很难把数据库跑满的.
数据库核心数, 内存大小最好也说下.
justest123
2022-01-25 15:07:48 +08:00
一楼说用队列没毛病,你自己可以控制生产速度、消费速度。当然,你每处理完一条或一批数据,自己加个睡眠等一下也不是不可以,终究是让服务器有个停顿,别一直持续超过告警阈值(真麻烦
Huelse
2022-01-25 15:11:41 +08:00
或者可以复制数据库去另台机器上操作
brader
2022-01-25 15:19:04 +08:00
@justest123 我们项目也有队列机制,但是这个场景不太适合队列做,因为我们是必须到点了,才进行数据统计的。
brader
2022-01-25 15:21:02 +08:00
@Gota 不止一个,是因为有好多个类似的任务,都差不多那个时间段跑,然后有历史原因,有些 sql 查询确实比较复杂,还没有索引,所以资源消耗比较厉害,后面我还优化了一部分慢的厉害的 sql 查询,会稍微好点,但是每日定时任务,有些时间段的还是任务比较重的
cais
2022-01-25 15:33:06 +08:00
谷歌有一个 guava 工具类里有 RateLimiter 这个类 可以限制速率
brader
2022-01-25 15:34:36 +08:00
@cais 知道如何实现速率限制,我更想搞清楚的是理论,如何设计会更流畅
Gota
2022-01-25 15:34:44 +08:00
@brader 我们用的也是阿里云的 RDS, 一般复杂的查询只是会慢一点, 但 CPU 消耗还好.
只有出现高并发写入的时候才会把 CPU 跑满.
你把每个任务的连接池最大连接数降到 1~2 个试试看, 然后直接把结果写成 CSV 用 LOAD DATA 应该会好一点.
BQsummer
2022-01-25 15:41:15 +08:00
只要不影响正常业务就不用管, 大数据部门很多作业晚上跑批会把资源打满, 做好资源隔离就行.
简单场景加个 sleep 不是不行, 主要是速率不可控,太小了效果不大; 太大了处理速度不行;现在调好了,过段时间任务处理时间变化了,又要调整.
上面说的限流都行.
cais
2022-01-25 15:48:35 +08:00
@brader 理论可以参考官方文档,至于你说的设计,其实这种限流就要根据你实际服务器性能和业务数据处理复杂度来测试才行,
我们跑的定时任务设计,执行定时任务 把需要处理的数据推到 mq 里--这里会限加限制
mq 消费端处理数据--这里也加限制
两边都加限制,再根据你们的业务场景调整限流值,只要不超过预警额就行了把。
RainCats
2022-01-25 17:28:29 +08:00
@brader 那就跟领导说,服务器水平拉跨,需要氪金了
RudyS
2022-01-25 17:36:19 +08:00
如果没有明显的设计缺陷,没有明显的用户体验问题;那么就说是硬件性能拉胯
cnoder
2022-01-25 17:58:32 +08:00
跑脚本加队列的话是有点麻烦了,sleep 一下吧
hangszhang
2022-01-25 18:21:40 +08:00
单机就 guava rate limiter ,分布式就 redis 限流
libook
2022-01-25 18:53:02 +08:00
尽可能避免使用定时任务方案,看有没有方法把定时过程转化成实时过程。
另外资源占用率从来不是主要监控指标,你要看具体操作花费的时间,操作时间过长再看是否是有资源占用异常,有的时候资源占用率高是因为利用效率高。

1. 首先看一下索引是不是可以优化,大多数据库性能问题其实都是由于索引优化不到位,有时候看之前觉得没问题,仔细看过索引之后才发现有问题;
2. 建立一些缓存机制,但缓存维护是个难题,一不小心就会导致 Bug ;
3. 限流,但治标不治本,比如极限情况下一个任务处理时间超过 24 小时,那几本就打破了一天一次的要求;
4. 升配,用云服务的话可以考虑仅在跑定时任务的时间按需高配,跑完再降配;
5. 分布式数据库,比如一些大数据架构。
wd
2022-01-25 19:08:40 +08:00
买的难道是 80% cpu 吗?自己花钱买的 cpu 为啥不能用 100% ..

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/830502

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX