rust 重写 xxl-job 的项目 ratch-job，第一个对外正式版本 v0.1.4 发布，任务调度 tps 可以稳定超过每秒 1 万次，感兴趣的同学欢迎试用、交流反馈。

[heqingpan]

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

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

项目地址： ratch-job

ratch-job 开发计划

1. 完成一个包含核心内容，满足大部分用户使用场景的初始正式版本;
2. 追平 xxl-job admin 现有的功能；
   1. 支持任务管理
   2. 支持按任务执行计划和指定的触发策略调度任务
   3. 支持查看任务执行记录
   4. 支持查看执行器对应的任务执行日志
   5. 控制台支持用户管理、登陆验证与权限控制
3. 完全兼容 xxl-job 协议前提下增强调度平台功能
   1. 任务失败重试支持配置对应的超时失败、重试次数与重试间隔；（ xxl-job 不支持配置重试间隔）
   2. 控制台触发支持指定执行器进行触发；
   3. 调度类型计划支持固定延时调度：上一个任务完成后延时固定秒数后新触发一次任务；
   4. 任务调度失败，通过内置消息监听中心支持配置多种渠道通知；
   5. 支持任务导入、导出
   6. 支持应用数据备份、恢复
   7. 支持 open api 管理 ratch-job 的任务调度；目前核心接口已完成，待增加认证机制与对应的文档；
4. 需要增强协议后增加功能 （需要等上面的内容稳定后才会开始）
   1. 支持自定义分片任务；（目前 xxl-job 只有全量分片任务）
   2. 移除任务平台主动对执行器服务发起请求的网络路由强依赖，需要使用类似 grpc 这类的长链接协议；

性能

环境	任务数	任务调度 tps	cpu 使用率(单核占比)	内存(M)
docker	100	100	5.2%	20M
ubuntu	1000	1000	32%	80M
mac m1	2000	2000	18%	90M
ubuntu	5000	5000	107%	270M
ubuntu	10000	10000	220%	810M

• 100tps

• 1000tps

• 2000tps

• 5000tps

• 10000tps

项目地址： ratch-job； 认可项目的同学，请求给项目个星，感谢！

[yb2313]

这个是什么, 类似 airflow 那样的东西吗

[heqingpan]

@yb2313 有点类似，xxl-job 和业务应用联系更紧密一些，它支持在业务应用进程调度执行任务。

[KInG2]

@yb2313 类似于 crontab 吧

[yangg]

不错正在找相关的东西。

[heqingpan]

@KInG2 crontab 相对上面提到的服务，功能上还是太简陋了些。比如单点，任务管理、任务执行状态、任务执行记录查看等功能都不能很多支持。
xxl-job 是个比较流行的分布式调度平台，搜索一下应该就可以知道它是干什么的。

[foufoufm]

感谢，有帮助，想知道服务稳定吗？ 如果合适的话，可以拿来先上手写自己项目上的定时任务

[guotie]

做成云服务去赚钱

[heqingpan]

@foufoufm
服务目前应该算比较稳定。
我也是 r-nacos 的作者，这是我用 rust 重写的第二个中间件服务。
在发布前除了常规的功能测试，还专门写了工具模拟真实的性能压力测试（结果可参考上面的性能说明）。
在稳定性这块我已尽力做到最好才发出来，我对这个版本的功能稳定性还是比较有信心的。

[CloudnuY]

好棒，准备在测试环境先替换上试试

[heqingpan]

@CloudnuY
很合理的策略，在测试环境充分测试验证后，才能考虑在正式环境使用。

[heqingpan]

使用过程中有遇到什么问题欢迎提 issue 反馈。

[heqingpan]

@guotie
这种应该需要在云服务商提供才能走通。
精力只足够写写开源代码，暂时不考虑这块。

[KInG2]

@heqingpan 主要碰到好多人就配置个定时调用接口，我感觉不如配置 crontab 了，还方便点，具体的深度使用我觉得的看业务的需求。

[PeiXyJ]

@KInG2 这个更适合有多个服务,比如我上的 K8S 每个 Service 都有多个副本,那么就需要 XJ 这样的帮我调用其中一个 Service 做业务处理,而不是多个 Service 都同时做.

[PeiXyJ]


[PeiXyJ]

[ddxx200]

这个不错，点赞

[heqingpan]

@KInG2 确实具体的要看业务需求。
如果调用的服务小概率失败影响不大，任务变更不频繁用 crontab 也比较方便。
如果还需要额外的配套进行保障的话，使用这类服务应该会方便些。

[heqingpan]

@foufoufm
@CloudnuY
@ddxx200
感谢支持。
如果使用遇到什么问题欢迎反馈。