V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
brader
V2EX  ›  程序员

请教个定时任务处理问题

  •  
  •   brader · 119 天前 · 1749 次点击
    这是一个创建于 119 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    3:其他更好的方法?

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

    1. 首先看一下索引是不是可以优化,大多数据库性能问题其实都是由于索引优化不到位,有时候看之前觉得没问题,仔细看过索引之后才发现有问题;
    2. 建立一些缓存机制,但缓存维护是个难题,一不小心就会导致 Bug ;
    3. 限流,但治标不治本,比如极限情况下一个任务处理时间超过 24 小时,那几本就打破了一天一次的要求;
    4. 升配,用云服务的话可以考虑仅在跑定时任务的时间按需高配,跑完再降配;
    5. 分布式数据库,比如一些大数据架构。
    wd
        20
    wd  
       119 天前 via iPhone
    买的难道是 80% cpu 吗?自己花钱买的 cpu 为啥不能用 100% ..
    4771314
        21
    4771314  
       118 天前
    最简单的就是限流,如果限流不能解决就需要看下具体的脚本有没有优化的空间,优化就两个思路:
    1. 脚本逻辑的优化
    2. sql 语句的优化
    最后就是升级配置,任务就是很大、很慢,那就只能升级硬件的配置来处理,但是这种比较浪费资源,因为你只有在执行脚本的时候需要大量的资源,但是平时是不需要这么多的资源的。
    ql562482472
        22
    ql562482472  
       118 天前
    1
    brader
        23
    brader  
    OP
       118 天前
    @libook 对的,跑脚本期间 mysql 实例的 cpu 和 io 飙升,大部分是一些慢 sql ,没加索引等等问题引起的,严重的一些定时任务我已经优化了 sql 索引问题了,但是这种屎山项目几百上千定时任务。。。又不给时间处理这些,经常有其他需求,无语
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2373 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 16:05 · PVG 00:05 · LAX 09:05 · JFK 12:05
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.