黑名单, 数据库存储黑名单

@hzzhzzdogee aliyun 监控

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

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

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

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

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

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

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


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

@arischow 我已经解决了, 就是去掉 xxl job

@yongjing 最多的是 xxl_job_info, 另外是 xxl_job_log

@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

@JinTianYi456
@yongjing
我清理过

最终还是去掉这个组件, 用别的语言重写了, Java 我不太懂

@stinkytofu 就是 xxl job 的慢 查询, 用 Elixir 重写了
@keepRun

@dlmy 哪黑了?

top 1 的慢查询都是 xxl job 的
https://cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-CXh3WYn7C3-g66UmVt6nLQ1pHw25Aguh2z9l3wvSH4.png

@dunhanson 加内存呗

为啥发明一种新语言直接用 python 不好吗?
比如 https://www.pulumi.com/

@worldqiuzhi 正解

@sniperking1234 挂个 nfs,自己 程序处理

pod 环境变量里读取配置

用 configmap 或者 secret

pod 重启就行