最近在计划用 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 服务这个项目，大家有什么建议或者期望欢迎一起讨论。

[momowei]

大佬还是强

[3085570450tt]

@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 在这方面还是别来碰瓷了