为啥有人用 xxl job

[lidashuang]

把 xxl job 去掉, 数据 io 立马正常了

https://cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-d3nSG4K4GL-ENRkABrCGyVHa20BISGvbsrOCRiOL6w.png

[cp19890714]

确实有这个问题。需要定期清理日志，我现在是用数据库运维工具自动清理。

你是懂起语言艺术的，6 个字，即骂了 xxljob ，也骂了用 xxljob 的人。

[zsdroid]

提个 issue 比发牢骚更麻烦吗？

[Mogugugugu]

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]

一个是 JobScheduleHelper 类中的 scheduleThread 线程，会一直去扫 xxl_job_info 表，取出即将要执行的任务；

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

这两个组件会一直扫描库表，当库表中数据量过大时，可能会出现这类问题，麻烦你去看看 xxl-job 的 issues ，去看看这个中间件的源码，不要出了问题就在这里鬼叫

[dlmy]

团队如果没人精读过源码，解决不了常见的问题，当初为什么要选用这个技术呢？

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

啥都不懂，出了问题就会鬼叫，你有本事自己也写几个中间件出来，把生态建设起来呀，别躲在键盘后面尬黑好么

[zhongjun96]

@lidashuang #17 xxl_job_info 这里是任务列表，任务怎么会比日志还多？

[burymme11]

如果用 Elixir 重写后的业务逻辑出了问题，我想看到你怒喷 Elixir 的帖子。

[leeg810312]

开源的东西不是收费产品，得自己运维，既然有很多人在用，说明主要特性符合需求，有些非关键特性可以自己开发补足或用其他方法解决。

[wbd31]

https://github.com/xuxueli/xxl-job/issues/2415

2021 年的 issue 居然还是 open 状态。。我倒是支持 op 的看法。

[lidashuang]

> 你是懂起语言艺术的，6 个字，即骂了 xxljob ，也骂了用 xxljob 的人。


@cp19890714 引入这个的人给我带来了太多的痛苦

[lidashuang]

@burymme11 java 微服务搞成单体, 机器配置降了很多, 延时好了很多, 之前 Java 服务一启动, 那 cpu 可壮观了

[statumer]

提醒您啊，对象存储 cos bucket 地址暴露出来是很危险的，最好删掉了

[lidashuang]

@statumer 感谢, 我专门拿来当图床的, 没啥大问题

[lidashuang]

@dlmy
> 团队如果没人精读过源码，解决不了常见的问题，当初为什么要选用这个技术呢？

我不认识之前引入这些的人, 我帮别人优化, 如果这个东西需要看源码才能用好的话? 我真的不想用, 很累

[lidashuang]

@dlmy 我是不懂, 所以我不用了啊, 吐槽还不行?

[dlmy]

@lidashuang #34 既然你接盘了这套东西，至少得知道分布式任务调度框架会有调度中心跟执行器，然后会有一个分布式协调中心，这些基本的东西，你应该得知道呀。

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

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

你好好拿出来说明，大家一起帮忙看下，不就能很快解决么，你直接张嘴就尬黑，这样谁会认真帮你去看问题？

[lidashuang]

@dlmy 我自己已经解决了 才发的帖子, 我就是发泄情绪哈哈

[hzzhzzdogee]

OP 这个图表是什么工具提供的呀

[cowcomic]

在多个项目上用到了，主要原因就是不重复造轮子，我对于这类中间件的质量概念是存活时间+大家的使用量+更新频率+对应的业务场景+issue=品质，xxljob 从开始就还是比较信任的，没怎么做测试就直接使用。一直也的确没什么问题。跟他对应的比如 shardingsphere-proxy 和 debezium ，这两个都是比较早期就开始用，用的人也不多，业务也比较核心，所以做了大量测试才引入

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

仅供参考

[lidashuang]

@hzzhzzdogee aliyun 监控