最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs
heqingpan · 2025 年 1 月 21 日 · 6358 次点击这是一个创建于 360 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人是 r-nacos 作者，在完成 rust 重写 nacos 服务主体功能后，最近在计划用 rust 重写 xxl-job 服务。
本人在写服务端前习惯写个客户端，方便深入理解协议与开发过程中各类场景的验证。
刚才目前 rust 没有 xxl-job 的 sdk 便先写一个 xxl-job rusk sdk 。
sdk 对应的项目是 xxljob-sdk-rs ,目前主体功能已可用，具体使用方式可以参考项目 readme 。感兴趣的 rust 开发可以观注下，如果使用过程中遇到什么问题可以到 github 上提 issues 。
对于用 rust 重写 xxl-job 服务这个项目，大家有什么建议或者期望欢迎一起讨论。
 |
1
198plus 2025 年 1 月 21 日 via Android
能做什么呀，读 readme 有点没看懂
|
 |
2
heqingpan OP xxl-job 是一个分布式调度平台，可以简单理解为分布式定时器。
它分服务端调度和客户端执行器，目前完成的 sdk 只是客户端支持接入服务端当做一个执行器，重写服务端正在计划中还没有完成。 |
 |
3
Plutooo 2025 年 1 月 21 日
r-nacos 确实好用，点个赞
|
 |
4
burymme11 2025 年 1 月 21 日
客户端执行器可以自动注册，但是还需要再手动添加，一旦 job 多了，手动在页面上加，体验很糟。
个人建议进一步完善自动注册。 |
|
5
burymme11 2025 年 1 月 21 日
还有异常报警，建议添加 企微/钉钉等目前主流信道
|
 |
6
v2zzzzz 2025 年 1 月 21 日
看了下我们测试的 nacos 随便就占了 1G 内存，r-nacos 估计能节省 90%，要是 UI 也能对齐就好了，点个赞，加油
|
 |
8
louhubiao 2025 年 1 月 21 日
xxl-job 的源码阅读，有推荐的博客吗，想深入了解一下
|
 |
9
FrankAdler 2025 年 1 月 21 日
支持一下
|
|
10
heqingpan OP @burymme11
自动注册与报警方式需求收到，自动注册目前协议上是不支持的，后面考虑新增扩展 openapi 支持，不过对应的执行器 sdk 也需要增强才可能可以支持。 另外自动注册的任务会解决少部分信息，可能的需要人工修改补充信息后才可以启用。 |
 |
12
Ayanokouji 2025 年 1 月 21 日
重新设计一个吧，xxl-job 真不咋样
|
|
13
heqingpan OP |
|
14
heqingpan OP @Ayanokouji
我重写时肯定是会重新设计的，也会增加自己的 openapi 。 只是会第一个兼容 xxl-job 的协议，加入已有的流行生态，项目才能快速启动。 如果有其它流行任务调度协议后面也会考虑兼容支持，这块有推荐的吗？ |
 |
15
LieEar 2025 年 1 月 21 日
厉害，r-nacos 很🐂，印象深刻。期待改写效果
|
|
16
Ayanokouji 2025 年 1 月 21 日
|
|
17
Ayanokouji 2025 年 1 月 21 日
@heqingpan 最终不管兼容谁的协议，希望加上 namespace 资源隔离
|
|
18
heqingpan OP @Ayanokouji 加上 namespace 做资源隔离，这是一个不错的建议，计划会支持。
|
 |
19
cornorj6 2025 年 1 月 21 日
支持作者，刚刚去看了 rnacos ，把我原先的 nacos 内存从 1011M 降到 8M ，太给力了。同样的 xxl-job 我也有用到，占用了 700M ，如果能像 rnacos 那样节省 99%，真是太棒了。PS：有没有考虑把 elasticsearch 也优化下，这货占了几 G 。
|
 |
20
flowerains 2025 年 1 月 21 日
是 rnacos 的作者吗？我当时真有点想在生产环境直接用 rnacos 了，迫于稳定性最终还是没采用。
|
 |
21
importmeta 2025 年 1 月 21 日
不如找个国外项目用 Rust 重写, 开捐款, 国产项目纯用爱发电.
|
|
22
heqingpan OP @cornorj6 重写 xxl-job 节省 99%不一定能达到，节省 95%的把握还是比较大的。
一阶段只能把主要精力投入一个项目，es 就看看其它人是否有兴趣吧。 我印象中已经有用 rust 写的日志服务，不过不是完全兼容协议，感兴趣可以去搜索一下。 |
|
23
heqingpan OP @flowerains 表示理解，这个稳定性的确认还是要花一段时间的。
比如测试环境不重启持续测试运行个三个月、半年，大概就可以有较大的把握。 后面还有机会😀 目前基于收到的反馈，现在已经很稳定，所以我才有精力写下一个项目。 |
|
24
heqingpan OP @importmeta 目前有正经不需要
|
|
25
heqingpan OP 目前有正经工作不需要考虑太多，写这个主要动力还是爱好。
写的项目自己也会是用户，国外的没接触过反倒没动力写。 |
 |
26
ACCI 2025 年 1 月 21 日
大数据的任务调度用 dolphin scheduler 或者 airflow 比较多吧. xxljob 可能 java spring 项目用的多些吧.
|
 |
28
mark2025 2025 年 1 月 21 日
@3085570450tt ES 在 pg+插件（比如 paradedb ）之前没有前途了
|
 |
29
beneo 2025 年 1 月 21 日
点赞，之前 rust + docker + mac 开发 + linux 部署 直接劝退，来看看怎么实现的
|
 |
31
des 2025 年 1 月 22 日
赞，先收藏了
|
 |
32
Honwhy 2025 年 1 月 22 日
赞，up 主想法真不错，给 Javaer 一个思路，入坑 Rust
|
|
33
heqingpan OP @Kevinyy 你说的通用告警是指内部还是外部？
内部的话会设计成通用的，已接入告警渠道支持方便切换。 外部的话，目前有什么通用的协议吗？ 告警中心是不是也可以理解为像邮箱、企微、钉钉之类的另外一个告警渠道？ |
 |
35
nm1st 2025 年 1 月 22 日
r-nacos 有用过,很牛,支持
|
 |
37
mulychou 2025 年 1 月 22 日
r-nacos 用在研测环境，真的节省了很多内存空间，很牛，支持
|
 |
38
visper 2025 年 1 月 22 日
r-nacos 已经在开发环境使用一年。没有什么问题。
|
|
39
heqingpan OP @5261 用 go 重写应该也可以提前一些但效果应该比 rust 还会差一些。
r-nacos 用 go 写的话应该达不到现在这个效果。 对 go 和 rust 的熟悉度差不多情况下，一般会选效果最好的，何况我现在使用 rust 便顺手一些。 |
 |
40
UB 2025 年 1 月 22 日
@heqingpan 文档啥的，可以在详细丰富一下💪💪💪。比如它的背景，目的，具体的使用场景（比如结合 actix, axum 等 web 框架的最佳使用）
|
 |
41
momowei 2025 年 1 月 22 日
大佬还是强
|
 |
43
coolcoffee 2025 年 1 月 22 日
哇塞！现在才看到还有 r-nacos 这个应用，赶紧部署一个试试看。
xxx-job 和 es 目前也是内存大户，属于不得不用的类型，因为看其他竞品要么功能不如它强大，要么还不如它开放。 |
 |
45
5waker 2025 年 1 月 22 日
r-nacos 测试环境用的真的很爽，期待大佬的 xxl-job
|
 |
46
PaulSamuelson 2025 年 1 月 22 日
会内置 k8s api 么？
|
|
47
heqingpan OP @PaulSamuelson 应用本身不会直接和 k8s 耦合，然后也是支持部署到 k8s 中。目前 r-nacos 是支持 k8s helm 方式部署的。
|
|
48
heqingpan OP @3085570450tt 目前 r-nacos 的文档主要是使用说明，其它方面的后面有空慢慢补。
|
|
49
heqingpan OP @5261 是的中间件模型逻辑都比较稳定，对性能稳定性要求较高，用 rust 刚好合适。
业务需求变化比较大，更关心快速变化的场景下开发效率，性能再其次，用 go 、java 之类比较合适。 |
 |
50
ingnoscemihi 2025 年 1 月 22 日
rust 太稳定了，期待
|
|
51
cornorj6 2025 年 1 月 22 日
@heqingpan 感谢作者的无私奉献。关于 xxl-job ，在我使用过程中碰到过 2 个问题，第一个问题是每个任务每执行一次都会产生一个小的日志文件，当任务特别多执行很频繁的时候，这些日志会把服务器 inode 数量耗光。第二个问题是 xxl-job 有个日志表 xxl_job_log 数据量特别大时（任务执行比较多且频繁），会严重影响数据库性能，它会不定期查询这个表来判断任务完成情况。建议做成按照日期的分区表。
|
|
52
heqingpan OP @cornorj6 这个日志问题已收到，感谢反馈。
关于服务端日志的问题，重写的服务可以避免这个可能问题。 重写后不依赖日志做任务状态的判断，任务状态计划会放在内存中；日志只有用户查看时才会去查询。日志支持按最长时间或最大数量保存。 关于执行器的日志，目前这个是由 sdk 控制，同时目前的协议也不支持从服务端发起删除执行器的日志，所以这个问题本次无法解决。 后续可以考虑通过扩展 sdk 方式解决。 |
 |
54
psxf 2025 年 1 月 22 日
点个 star 支持一下，大佬执行力太强了，之前我也有类似的想法，用 rust 重新 xxl-job ，入门 rust 好几次都没能成功，大佬加油，期待
|
 |
55
fcfangcc 2025 年 1 月 22 日
搭车宣传下 Python 版本的 xxl-job executor [PYXXL 文档]( https://github.com/fcfangcc/pyxxl)
|
 |
56
dddd1919 2025 年 1 月 22 日
不如 rust 写个 dophinscheduler
|
 |
57
viking602 2025 年 1 月 22 日
支持！ 期待一下 ！！
|
|
58
heqingpan OP @dddd1919
我刚查了一下 dophinscheduler 的架构。它分 master 和 worker ，然后基于 zk 做集群。 它与 xxl-job 架构上区别比较明显；它的 worker 是独立的进程； xxl-job 执行器是嵌入业务服务进程中，与业主系统连接更紧密；它们算两个类型的调度系统。 本次暂不考虑支持 dophinscheduler 这类模式。 |
|
59
heqingpan OP |
|
61
dddd1919 2025 年 1 月 22 日
@heqingpan #58 xxl-job 相比较系统内 scheduler 和 crontab 的模式优势就是把调度从服务内解耦并且集中管理起来，解决了调度策略问题，但对任务编排和异构调度的支持太弱鸡，对比起来 dohpinscheduler 的设计应该是更进一步，worker 的引入增强了调度场景的泛用性，而且支持 DAG 这玩意才应该是任务调度更进一步的形态，不仅单点规划，还能全局串接，对于任务编排更透明
|
|
63
heqingpan OP  1
更新一下项目信息：
项目第一个正式版本已发布, 项目地址 [ratch-job]( https://github.com/ratch-job/ratch-job) |
 |
64
M2 2025 年 12 月 1 日
r-nacos 已用上，效果杠杠，期待 xxl-job 的。
|
Select Language