时间:2021-07-01 10:21:17 帮助过:13人阅读
可以通过建立表[id,name,status,func,timer,last_time,created_at] 来统一存放项目中的计划任务脚本,通过简单的配置
能将各计划任务抽象成简单的任务类,然后通过crontab中配置的单个入口对其进行统一访问,从而减少了上线代码对
线上服务器环境进行修改的麻烦.
然后此处有一些坑,因为任务按功能性质划分可能有好几种,比如:
1. 单次执行,立刻结束,同一时刻可运行多个实例
2. 守护进程,同一时刻只能运行一个实例
对 第二种 需要 加锁 机制,还要防止程序因为出现爆错,异常等情况没有解锁,导致不能再次启动此种任务
对于此种任务还需要考虑运行期间如果因其他需求变更,如何快速方便的终止此任务
猜想 通过 任务id 来实现锁机制,每次任务执行时均需要申请锁,每次申请的锁均有固定的使用配额,此种任务
每批次执行完成后均需消耗一次使用配额,当配额为0时则需要向系统重新申请锁.
lock_id: $task_id
lock_{$task_id}_quota: $quota
每次重新申请锁,均需再次读取任务配置表中该任务的配置信息
如果申请失败(-1),则关闭此次执行,等待下次执行. 这样当想中止此种任务时可采取2种方案:
1. 中止本次,只需将其使用配额设为-1
2. 完全禁止,重置本任务的status为禁用,再重置其使用配额为-1
任务结束之后,要释放锁,如果锁释放失败,需要有一个 无效锁检测机制来强制释放
无效锁的判定:
关键是 如何确定 任务实例是否是活着的,锁配额 < 1 能否认定是无效锁.会不会出现任务在重新申请锁的过程中
被 无效锁检测机制给干掉?
干掉之后是否有影响?