新特性: 副本重启后的任务恢复

[dxyinme]

讨论来源： https://github.com/libi/dcron/issues/25#issuecomment-1418892887

实现方式： 增加一种新的任务模式，可以将任务本身序列化后存储在redis/etcd中，在重启之后，获取当前副本所属服务类型的所有任务。

[libi]

任务本身可能是项目关联的任意复杂逻辑，所以如果需要考虑序列化存储，dcron 就得有 “将序列化后的文本重新加载到内存后动态执行” 的能力，假设逻辑是用 go 编写的话，就得有动态执行 go 的能力，感觉难度不小😓。

[dxyinme]

任务本身可能是项目关联的任意复杂逻辑，所以如果需要考虑序列化存储，dcron 就得有 “将序列化后的文本重新加载到内存后动态执行” 的能力，假设逻辑是用 go 编写的话，就得有动态执行 go 的能力，感觉难度不小sweat。

感觉并不需要动态执行golang的能力，就比如我在example里面定义的WriteJob，如果这个Job被加入到dcron中，就说明这个Job所属的类型已经以代码形式存在在这个服务内部，而我们只需要序列化和反序列化他的参数就行了。不过如果是直接以func定义的任务，那确实没办法，也没有必要做持久化了。个人感觉这类任务的一个例子就是：“从一个数据库里面统计某个类型的字段数量，然后将统计结果写入另一个数据库内”，对于这种任务，序列化的内容只需要两个数据库的连接参数和表名就可以了，具体逻辑已经定义好了。

[libi]

这样是不是单个任务是被拆分成了 代码逻辑 和 任务数据 两个部分?

[dxyinme]

这样是不是单个任务是被拆分成了 代码逻辑 和 任务数据 两个部分?

我觉得是这样的。代码逻辑没必要序列化，因为已经在程序里面写好了；但是任务数据是可以做到的。

[libi]

这样的话代码逻辑的调度部分和现在是一样的,任务数据的调度得想想怎么保持完全一致

[dxyinme]

这样的话代码逻辑的调度部分和现在是一样的,任务数据的调度得想想怎么保持完全一致

嗯，这个我最近想想怎么弄