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

为啥有人用 xxl job

  •  
  •   lidashuang · 2023-09-28 00:00:41 +08:00 · 6491 次点击
    这是一个创建于 434 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  2023-09-28 12:36:24 +08:00
    用 Elixir 重写了业务逻辑, 跑的快快的
    第 2 条附言  ·  2023-09-28 12:36:56 +08:00
    第 3 条附言  ·  2023-09-28 12:44:08 +08:00
    我搞不懂一个 "成熟的组件" 需要我小心翼翼的使用
    第 4 条附言  ·  2023-09-28 23:48:08 +08:00
    使用时间长了之后产生慢 SQL #2415
    https://github.com/xuxueli/xxl-job/issues/2415
    40 条回复    2023-10-03 23:25:53 +08:00
    keepRun
        1
    keepRun  
       2023-09-28 01:35:12 +08:00 via Android
    你这属于没用好工具吧
    stinkytofu
        2
    stinkytofu  
       2023-09-28 01:42:03 +08:00
    我不信这个库本身有这样明显的问题, 检查一下你的代码吧
    securityCoding
        3
    securityCoding  
       2023-09-28 04:05:18 +08:00 via Android
    在写日志吧
    Mogugugugu
        4
    Mogugugugu  
       2023-09-28 08:59:40 +08:00
    所以问题是什么呢?
    dlmy
        5
    dlmy  
       2023-09-28 09:04:24 +08:00
    如果确定是 xxl-job 的问题,可以去提 issue ,别在这尬黑
    zzzb002
        6
    zzzb002  
       2023-09-28 09:05:42 +08:00
    是不是有个异常日志一直报?那种很频繁的,可能会造成 IO 上去,网上解决方案很多
    yongjing
        7
    yongjing  
       2023-09-28 09:15:30 +08:00
    log 表数据量有多少? 分页查询 COUNT 总条数,会导致扫全表, 记得及时清理~
    limyel
        8
    limyel  
       2023-09-28 09:19:15 +08:00
    这种应用广泛的中间价,出问题了一般先考虑一下是不是自己的问题。
    limyel
        9
    limyel  
       2023-09-28 09:19:38 +08:00
    @limyel 中间价 -> 中间件
    xiaocaiji111
        10
    xiaocaiji111  
       2023-09-28 09:20:08 +08:00
    找到问题再黑,企业这个用的多的很,还是规模化的企业。就是 ui 界面之类丑了些。
    panzhc
        11
    panzhc  
       2023-09-28 09:20:43 +08:00
    xxljob 默认首页是运行报表,是查数据库的,如果运行时间比较久,日志表里数据量比较大,就会导致数据库 iops 高,而且是首页,任何人登录以后都会查一下。
    解决办法要么清日志,要么改下登录后的默认首页。
    arischow
        12
    arischow  
       2023-09-28 09:34:32 +08:00
    如果你真的想解决问题,请不要用这种反问。
    JinTianYi456
        13
    JinTianYi456  
       2023-09-28 09:36:19 +08:00
    TRUNCATE xxl_job.xxl_job_log;
    lidashuang
        14
    lidashuang  
    OP
       2023-09-28 12:32:50 +08:00
    @stinkytofu 就是 xxl job 的慢 查询, 用 Elixir 重写了
    @keepRun

    @dlmy 哪黑了?

    top 1 的慢查询都是 xxl job 的
    https://cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-CXh3WYn7C3-g66UmVt6nLQ1pHw25Aguh2z9l3wvSH4.png
    lidashuang
        15
    lidashuang  
    OP
       2023-09-28 12:34:49 +08:00
    @JinTianYi456
    @yongjing
    我清理过

    最终还是去掉这个组件, 用别的语言重写了, Java 我不太懂
    lidashuang
        16
    lidashuang  
    OP
       2023-09-28 12:38:20 +08:00
    @panzhc 管理后台没人查, 就是 xxl job 自己跑的逻辑查
    比如

    SELECT id FROM `xxl_job_log` WHERE !( (trigger_code in (0, 200) and handle_code = 0) OR (handle_code = 200) ) AND `alarm_status` = 0 ORDER BY id ASC LIMIT 1000


    SELECT t.id, t.job_group, t.job_cron, t.job_desc, t.add_time, t.update_time, t.author, t.alarm_email, t.executor_route_strategy, t.executor_handler, t.executor_param, t.executor_block_strategy, t.executor_timeout, t.executor_fail_retry_count, t.glue_type, t.glue_source, t.glue_remark, t.glue_updatetime, t.child_jobid, t.trigger_status, t.trigger_last_time, t.trigger_next_time FROM xxl_job_info AS t WHERE t.trigger_status = 1 and t.trigger_next_time <= 1695571207054 ORDER BY id ASC LIMIT 6000
    lidashuang
        17
    lidashuang  
    OP
       2023-09-28 12:40:02 +08:00
    @yongjing 最多的是 xxl_job_info, 另外是 xxl_job_log
    lidashuang
        18
    lidashuang  
    OP
       2023-09-28 12:40:47 +08:00
    @arischow 我已经解决了, 就是去掉 xxl job
    yanhuamiluan
        19
    yanhuamiluan  
       2023-09-28 13:59:36 +08:00
    吃了个烂苹果, 问为啥有人要吃苹果
    Masoud2023
        20
    Masoud2023  
       2023-09-28 14:03:00 +08:00
    有人用不代表这东西质量方面过关。

    这东西本身工程质量就不太好,但是用着真的快糙猛,时间长了也就这样了。
    cp19890714
        21
    cp19890714  
       2023-09-28 14:19:02 +08:00   ❤️ 2
    确实有这个问题。需要定期清理日志,我现在是用数据库运维工具自动清理。

    你是懂起语言艺术的,6 个字,即骂了 xxljob ,也骂了用 xxljob 的人。
    zsdroid
        22
    zsdroid  
       2023-09-28 14:50:40 +08:00
    提个 issue 比发牢骚更麻烦吗?
    Mogugugugu
        23
    Mogugugugu  
       2023-09-28 14:59:23 +08:00
    https://www.xuxueli.com/xxl-job/#5.22%20%E6%97%A5%E5%BF%97%E8%87%AA%E5%8A%A8%E6%B8%85%E7%90%86

    文档有说日志自动清理,不知道有人配置试过么
    dlmy
        24
    dlmy  
       2023-09-28 15:02:50 +08:00   ❤️ 1
    一个是 JobScheduleHelper 类中的 scheduleThread 线程,会一直去扫 xxl_job_info 表,取出即将要执行的任务;

    一个是 JobFailMonitorHelper 类中的 monitorThread 线程,会从数据库 xxl_job_log 表中查询执行失败并且报警状态码还未改变的定时任务,10s 执行一次;

    这两个组件会一直扫描库表,当库表中数据量过大时,可能会出现这类问题,麻烦你去看看 xxl-job 的 issues ,去看看这个中间件的源码,不要出了问题就在这里鬼叫
    dlmy
        25
    dlmy  
       2023-09-28 15:09:18 +08:00
    团队如果没人精读过源码,解决不了常见的问题,当初为什么要选用这个技术呢?

    你发这个帖,起个这样的标题,是想实际解决问题还是想让我们帮忙一起喷这个中间件呢?

    啥都不懂,出了问题就会鬼叫,你有本事自己也写几个中间件出来,把生态建设起来呀,别躲在键盘后面尬黑好么
    zhongjun96
        26
    zhongjun96  
       2023-09-28 15:24:54 +08:00
    @lidashuang #17 xxl_job_info 这里是任务列表,任务怎么会比日志还多?
    burymme11
        27
    burymme11  
       2023-09-28 16:19:34 +08:00
    如果用 Elixir 重写后的业务逻辑出了问题,我想看到你怒喷 Elixir 的帖子。
    leeg810312
        28
    leeg810312  
       2023-09-28 16:34:11 +08:00
    开源的东西不是收费产品,得自己运维,既然有很多人在用,说明主要特性符合需求,有些非关键特性可以自己开发补足或用其他方法解决。
    wbd31
        29
    wbd31  
       2023-09-28 17:27:29 +08:00
    https://github.com/xuxueli/xxl-job/issues/2415

    2021 年的 issue 居然还是 open 状态。。我倒是支持 op 的看法。
    lidashuang
        30
    lidashuang  
    OP
       2023-09-28 23:44:47 +08:00
    > 你是懂起语言艺术的,6 个字,即骂了 xxljob ,也骂了用 xxljob 的人。


    @cp19890714 引入这个的人给我带来了太多的痛苦
    lidashuang
        31
    lidashuang  
    OP
       2023-09-28 23:48:52 +08:00
    @burymme11 java 微服务搞成单体, 机器配置降了很多, 延时好了很多, 之前 Java 服务一启动, 那 cpu 可壮观了
    statumer
        32
    statumer  
       2023-09-28 23:51:47 +08:00 via iPhone
    提醒您啊,对象存储 cos bucket 地址暴露出来是很危险的,最好删掉了
    lidashuang
        33
    lidashuang  
    OP
       2023-09-29 00:07:53 +08:00
    @statumer 感谢, 我专门拿来当图床的, 没啥大问题
    lidashuang
        34
    lidashuang  
    OP
       2023-09-29 00:09:34 +08:00
    @dlmy
    > 团队如果没人精读过源码,解决不了常见的问题,当初为什么要选用这个技术呢?

    我不认识之前引入这些的人, 我帮别人优化, 如果这个东西需要看源码才能用好的话? 我真的不想用, 很累
    lidashuang
        35
    lidashuang  
    OP
       2023-09-29 00:10:36 +08:00
    @dlmy 我是不懂, 所以我不用了啊, 吐槽还不行?
    dlmy
        36
    dlmy  
       2023-09-29 09:43:53 +08:00
    @lidashuang #34 既然你接盘了这套东西,至少得知道分布式任务调度框架会有调度中心跟执行器,然后会有一个分布式协调中心,这些基本的东西,你应该得知道呀。

    当程序运行时,会启用哪些组件,这些组件里面包含了什么(比如 工作线程、工作线程池等)、分别干了什么(比如 扫表、调度、触发任务、通信)、哪些组件会占用服务器较多的资源(比如 间隔多久查一次表、sql 是怎样的),然后结合一些可观测性的指标,马上就能定位到源码了,这不就是程序员每天工作的日常吗?

    所以到底是你自己不够了解这套东西,还是这套东西本来就有问题呢?

    你好好拿出来说明,大家一起帮忙看下,不就能很快解决么,你直接张嘴就尬黑,这样谁会认真帮你去看问题?
    lidashuang
        37
    lidashuang  
    OP
       2023-09-29 10:46:59 +08:00
    @dlmy 我自己已经解决了 才发的帖子, 我就是发泄情绪哈哈
    hzzhzzdogee
        38
    hzzhzzdogee  
       2023-09-29 13:39:18 +08:00
    OP 这个图表是什么工具提供的呀
    cowcomic
        39
    cowcomic  
       2023-09-29 16:05:10 +08:00   ❤️ 1
    在多个项目上用到了,主要原因就是不重复造轮子,我对于这类中间件的质量概念是存活时间+大家的使用量+更新频率+对应的业务场景+issue=品质,xxljob 从开始就还是比较信任的,没怎么做测试就直接使用。一直也的确没什么问题。跟他对应的比如 shardingsphere-proxy 和 debezium ,这两个都是比较早期就开始用,用的人也不多,业务也比较核心,所以做了大量测试才引入

    至于日志的问题,当初在引入 xxljob 的时候就考虑到了,所以建设的时候就配套了清理机制,反映在架构设计相关文档和部署文档中,后续相关人交接也没出过什么问题

    仅供参考
    lidashuang
        40
    lidashuang  
    OP
       2023-10-03 23:25:53 +08:00
    @hzzhzzdogee aliyun 监控
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5290 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 03:47 · PVG 11:47 · LAX 19:47 · JFK 22:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.