最近在计划用 rust 重写 xxl-job 服务，顺便写了一个 xxl-job 的 rusk sdk: xxljob-sdk-rs

[heqingpan]

本人是 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 服务这个项目，大家有什么建议或者期望欢迎一起讨论。

rust重写xxl-job的项目ratch-job，第一个对外正式版本v0.1.4发布已发布。

初始正式版本包含核心内容，可满足用户核心使用场景：

1. 完成兼容xxl-job协议任务调度功能。
2. 完成内置的raft分布式存储，支持不依赖外部数据库进行分布式部署。
3. 自带web控制台管理。

项目地址： ratch-job

具体信息可参考本站新发的贴子: t/1122158

[198plus]

能做什么呀，读 readme 有点没看懂

[heqingpan]

xxl-job 是一个分布式调度平台，可以简单理解为分布式定时器。

它分服务端调度和客户端执行器，目前完成的 sdk 只是客户端支持接入服务端当做一个执行器，重写服务端正在计划中还没有完成。

[Plutooo]

r-nacos 确实好用，点个赞

[burymme11]

客户端执行器可以自动注册，但是还需要再手动添加，一旦 job 多了，手动在页面上加，体验很糟。
个人建议进一步完善自动注册。

[burymme11]

还有异常报警，建议添加 企微/钉钉等目前主流信道

[v2zzzzz]

看了下我们测试的 nacos 随便就占了 1G 内存，r-nacos 估计能节省 90%，要是 UI 也能对齐就好了，点个赞，加油

[zhuanggu]

@198plus 好多小公司的大数据调度任务直接用的就是 xxl

[louhubiao]

xxl-job 的源码阅读，有推荐的博客吗，想深入了解一下

[FrankAdler]

支持一下

[heqingpan]

@burymme11
自动注册与报警方式需求收到，自动注册目前协议上是不支持的，后面考虑新增扩展 openapi 支持，不过对应的执行器 sdk 也需要增强才可能可以支持。

另外自动注册的任务会解决少部分信息，可能的需要人工修改补充信息后才可以启用。

[heqingpan]

@louhubiao 没有。xxl-job 代码量不太结构也比较清晰，可以直接看代码。

[Ayanokouji]

重新设计一个吧，xxl-job 真不咋样

[heqingpan]

@Plutooo
@FrankAdler 感谢支持😊

[heqingpan]

@Ayanokouji

我重写时肯定是会重新设计的，也会增加自己的 openapi 。
只是会第一个兼容 xxl-job 的协议，加入已有的流行生态，项目才能快速启动。

如果有其它流行任务调度协议后面也会考虑兼容支持，这块有推荐的吗？

[LieEar]

厉害，r-nacos 很🐂，印象深刻。期待改写效果

[Ayanokouji]

@heqingpan 可以看下阿里云的 schedulex ，只不是是闭源。但是 api 有提供文档，https://help.aliyun.com/zh/mse/developer-reference/api-schedulerx2-2019-04-30-createnamespace-mse?spm=a2c4g.11186623.help-menu-123350.d_5_1_0_0_3_1_0.60391509FLhqKg&scm=20140722.H_2848778._.OR_help-T_cn~zh-V_1

[Ayanokouji]

@heqingpan 最终不管兼容谁的协议，希望加上 namespace 资源隔离

[heqingpan]

@Ayanokouji 加上 namespace 做资源隔离，这是一个不错的建议，计划会支持。

[cornorj6]

支持作者，刚刚去看了 rnacos ，把我原先的 nacos 内存从 1011M 降到 8M ，太给力了。同样的 xxl-job 我也有用到，占用了 700M ，如果能像 rnacos 那样节省 99%，真是太棒了。PS：有没有考虑把 elasticsearch 也优化下，这货占了几 G 。

[flowerains]

是 rnacos 的作者吗？我当时真有点想在生产环境直接用 rnacos 了，迫于稳定性最终还是没采用。

[importmeta]

不如找个国外项目用 Rust 重写, 开捐款, 国产项目纯用爱发电.

[heqingpan]

@cornorj6 重写 xxl-job 节省 99%不一定能达到，节省 95%的把握还是比较大的。

一阶段只能把主要精力投入一个项目，es 就看看其它人是否有兴趣吧。
我印象中已经有用 rust 写的日志服务，不过不是完全兼容协议，感兴趣可以去搜索一下。

[heqingpan]

@flowerains 表示理解，这个稳定性的确认还是要花一段时间的。
比如测试环境不重启持续测试运行个三个月、半年，大概就可以有较大的把握。
后面还有机会😀

目前基于收到的反馈，现在已经很稳定，所以我才有精力写下一个项目。

[heqingpan]

@importmeta 目前有正经不需要

[heqingpan]

目前有正经工作不需要考虑太多，写这个主要动力还是爱好。

写的项目自己也会是用户，国外的没接触过反倒没动力写。

[ACCI]

大数据的任务调度用 dolphin scheduler 或者 airflow 比较多吧. xxljob 可能 java spring 项目用的多些吧.

[UB]

@cornorj6 elasticsearch 已经有了用 rust 重写的了

[mark2025]

@3085570450tt ES 在 pg+插件（比如 paradedb ）之前没有前途了

[beneo]

点赞，之前 rust + docker + mac 开发 + linux 部署 直接劝退，来看看怎么实现的

[Kevinyy]

@heqingpan #10 建议设计成通用的告警推送的方式，这样可以接入告警中心，方便管理

[des]

赞，先收藏了

[Honwhy]

赞，up 主想法真不错，给 Javaer 一个思路，入坑 Rust

[heqingpan]

@Kevinyy 你说的通用告警是指内部还是外部？
内部的话会设计成通用的，已接入告警渠道支持方便切换。
外部的话，目前有什么通用的协议吗？

告警中心是不是也可以理解为像邮箱、企微、钉钉之类的另外一个告警渠道？

[heqingpan]

@Honwhy 欢迎入坑 rust ，用它来写中间件效果确实不错😄

[nm1st]

r-nacos 有用过,很牛,支持

[5261]

@heqingpan 为啥没选用 go 来写呢

[SilentBlade]

r-nacos 用在研测环境，真的节省了很多内存空间，很牛，支持

[visper]

r-nacos 已经在开发环境使用一年。没有什么问题。

[heqingpan]

@5261 用 go 重写应该也可以提前一些但效果应该比 rust 还会差一些。
r-nacos 用 go 写的话应该达不到现在这个效果。

对 go 和 rust 的熟悉度差不多情况下，一般会选效果最好的，何况我现在使用 rust 便顺手一些。

[UB]

@heqingpan 文档啥的，可以在详细丰富一下💪💪💪。比如它的背景，目的，具体的使用场景（比如结合 actix, axum 等 web 框架的最佳使用）

[momowei]

大佬还是强

[UB]

@mark2025 谢谢，我去看看其文档。

[coolcoffee]

哇塞！现在才看到还有 r-nacos 这个应用，赶紧部署一个试试看。

xxx-job 和 es 目前也是内存大户，属于不得不用的类型，因为看其他竞品要么功能不如它强大，要么还不如它开放。

[5261]

@heqingpan 确实，哪个顺手用哪个，rust 写中间件可能会好些，go 终究还是 web 业务开发会爽些，目前我也在 rust 入门的苦海中

[5waker]

r-nacos 测试环境用的真的很爽，期待大佬的 xxl-job

[PaulSamuelson]

会内置 k8s api 么？

[heqingpan]

@PaulSamuelson 应用本身不会直接和 k8s 耦合，然后也是支持部署到 k8s 中。目前 r-nacos 是支持 k8s helm 方式部署的。

[heqingpan]

@3085570450tt 目前 r-nacos 的文档主要是使用说明，其它方面的后面有空慢慢补。

[heqingpan]

@5261 是的中间件模型逻辑都比较稳定，对性能稳定性要求较高，用 rust 刚好合适。
业务需求变化比较大，更关心快速变化的场景下开发效率，性能再其次，用 go 、java 之类比较合适。

[ingnoscemihi]

rust 太稳定了，期待

[cornorj6]

@heqingpan 感谢作者的无私奉献。关于 xxl-job ，在我使用过程中碰到过 2 个问题，第一个问题是每个任务每执行一次都会产生一个小的日志文件，当任务特别多执行很频繁的时候，这些日志会把服务器 inode 数量耗光。第二个问题是 xxl-job 有个日志表 xxl_job_log 数据量特别大时（任务执行比较多且频繁），会严重影响数据库性能，它会不定期查询这个表来判断任务完成情况。建议做成按照日期的分区表。

[heqingpan]

@cornorj6 这个日志问题已收到，感谢反馈。

关于服务端日志的问题，重写的服务可以避免这个可能问题。
重写后不依赖日志做任务状态的判断，任务状态计划会放在内存中；日志只有用户查看时才会去查询。日志支持按最长时间或最大数量保存。

关于执行器的日志，目前这个是由 sdk 控制，同时目前的协议也不支持从服务端发起删除执行器的日志，所以这个问题本次无法解决。
后续可以考虑通过扩展 sdk 方式解决。

[cornorj6]

@heqingpan 感谢，期待 rust 版本的 xxl-job 。

[psxf]

点个 star 支持一下，大佬执行力太强了，之前我也有类似的想法，用 rust 重新 xxl-job ，入门 rust 好几次都没能成功，大佬加油，期待

[fcfangcc]

搭车宣传下 Python 版本的 xxl-job executor [PYXXL 文档]( https://github.com/fcfangcc/pyxxl)

[dddd1919]

不如 rust 写个 dophinscheduler

[viking602]

支持！ 期待一下 ！！

[heqingpan]

@dddd1919

我刚查了一下 dophinscheduler 的架构。它分 master 和 worker ，然后基于 zk 做集群。

它与 xxl-job 架构上区别比较明显；它的 worker 是独立的进程； xxl-job 执行器是嵌入业务服务进程中，与业主系统连接更紧密；它们算两个类型的调度系统。

本次暂不考虑支持 dophinscheduler 这类模式。

[heqingpan]

@ingnoscemihi
@cornorj6
@viking602

感谢这么多人支持与期待，我更有动力了😄。
会尽快设计并写一个最小可用版本出来，快的话过完年不久可以完成第一个版本。

[jhdxr]

@mark2025 基于 PG 还是算了。。。术业有专攻，传统的 RDBMS 在这方面还是别来碰瓷了

[dddd1919]

@heqingpan #58 xxl-job 相比较系统内 scheduler 和 crontab 的模式优势就是把调度从服务内解耦并且集中管理起来，解决了调度策略问题，但对任务编排和异构调度的支持太弱鸡，对比起来 dohpinscheduler 的设计应该是更进一步，worker 的引入增强了调度场景的泛用性，而且支持 DAG 这玩意才应该是任务调度更进一步的形态，不仅单点规划，还能全局串接，对于任务编排更透明

[heqingpan]

@dddd1919 DAG 这个只和服务端有关，后面倒是可以支持。

[heqingpan]

更新一下项目信息：
项目第一个正式版本已发布, 项目地址 [ratch-job]( https://github.com/ratch-job/ratch-job)

[M2]

r-nacos 已用上，效果杠杠，期待 xxl-job 的。