chunzi.me

正好项目中要定期运行一些计算工作，这才拿起 Catalyst::Plugin::Scheduler 的文档过了一遍。看起来很美妙，几乎和操作系统的 crontab 差不多了，于是立马上手测试。于是奇怪的问题来了，似乎设定的 schedule 事件并不是如期运行的，有时候就是不 run 有时候却意外的 run 了，查看最后运行时间也都不是设定的整点时间。于是怀疑时区设置，怀疑虚拟机的时钟，怀疑 yaml 的配置，怀疑模块本身有问题，总之试了很久都不行。那就改用 trigger 方式吧，那样还是需要用到操作系统的 crontab，而且似乎并没有运行设定的计划任务，返回用户登入界面了。

今天不甘，重新拿起来，发誓要克服掉。看源代码，总算静下心来看，才慢慢意识到，event 的执行是在每次 web 请求到来的时候被 dispatch 到的。这个时候这个 Plugin 才检查所有的计划任务，对照时间和授权，分别启动和执行。怪不得。然后重新阅读了文档，侧那，说得很明了，就是这么回事情，根本不是说你设定了 ‘* * * * *’ 就是每分钟准点触发运行的，作者假设你的应用系统基本上一直有请求到来，利用这个脉冲信号来触发计划任务的判断和执行。我原以为它是后台起了一个进程专门循环，每分钟看一下状态，然后触发的。所以这个定时的 schedule 看起来非常大兴，特别是像我现在的访问不均衡的应用。况且若干个 cron 之间的计算还有依赖关系，如果通过请求来触发的话，那就乱套了。然后还是回到 trigger 方式，文档中的例子，说是随便给你的应用一个请求，加上 scheduler_triigger=trigger_name 即可，不用管别的，好么，恰好我的应用根路径是一个重定向到用户登入界面，然后 cron 没有执行。试了一下其他的 uri ，非常顺利，通过。

经过一番曲折，到头来还是需要 crontab 定时发送一个 wget -q http://…./cron?schedule_trigger=trigger_name 的请求。anyway，解决了能运行就行。毕竟 cron 起来的计划任务是要用到 Catalyst 内部的 Model 什么的来写就的，换为普通的脚本，不但麻烦累赘，而且破坏了原来的 oo 接口。