feat(scheduler): add the module of scheduler #1959
Conversation
修复了初始化 bug 添加了 jobsMap 缓存 修复了拼写错误 扩展了 SafeMap 缩小公开的方法和结构体
dezhishen
changed the title
dezhishen
added
the
Module: Task
dezhishen
changed the title
| jobName string | ||
| cron gocron.JobDefinition | ||
| disabled bool | ||
| labels JobLabels |
There was a problem hiding this comment.
方便外部做任务过滤，如当前用户的任务，XX驱动的任务。
| runner JobRunner | ||
| params []any |
There was a problem hiding this comment.
这个runner直接写成闭包会不会好一些，本来对于调用者而言params大概率并不是一开始就是组织成[]any这种结构的，现在这种写法还要用反射检查参数数量和类型，让调用者直接提供func(ctx context.Context) error类型的闭包不仅写法更简单，还能在调用测实现编译期安全
There was a problem hiding this comment.
我又想了一下，我觉得这块可以参考驱动的设计，每种定时任务就像一种驱动，params就是驱动的addition，交给业务层去序列化和反序列化，jobBuilder可以只接收一个model.ScheduleTask结构体，从其config得到name，uuid，disabled，crontab等信息，然后model.ScheduleTask固定实现一个Execute(ctx context.Context) error方法，当做这里的runner
| Name string | ||
| scheduler gocron.Scheduler | ||
| jobsMap jobsMapType | ||
| jobDisabledMap jobDisabledMapType |
There was a problem hiding this comment.
这个map是不是value一定全是true，改成map[uuid]any，value存struct{}{}会不会好一些，不容易让人误以为存的是所有jobs: true/false
| lastRun, lastRunErr := job.LastRun() | ||
| nextRun10, nextRunErr := job.NextRuns(10) |
There was a problem hiding this comment.
立即获取LastRun和NextRuns应该不对吧，这两个随着任务的进行会发生变化，应该在OpJob里储存job，然后LastRun函数直接转发o.job.LastRun
| type safeMap[K comparable, V any] struct { | ||
| lock sync.RWMutex | ||
| data map[K]V | ||
| } |
2 participants
Description / 描述
这是任务调度器的核心能力封装，基于 github.com/go-co-op/gocron/v2
业务侧代码与gocron的耦合tags []string处理为labels map[string]string，方便外部管理，如区分job所属用户Motivation and Context / 背景
目前部分需求依赖定时任务的机制，让服务能定时处理某些事项。
Closes #XXXX
Relates to #XXXX
How Has This Been Tested? / 测试
Checklist / 检查清单
我已阅读 CONTRIBUTING 文档。
go fmtor prettier.我已使用
go fmt或 prettier 格式化提交的代码。我已为此 PR 添加了适当的标签（如无权限或需要的标签不存在，请在描述中说明，管理员将后续处理）。
我已在适当情况下使用"Request review"功能请求相关代码作者进行审查。
我已相应更新了相关仓库（若适用）。