我现在还采用了另一个方案,启动queue进程是永不退出的,workerman的工作进程作为守护进程来检测queue进程数量,这样有queue进程异常退出导致进程数不足时,workerman的工作进程可以补足数量。这样做可以把timer间隔设得比较大,事件推入队列也是实时的,因为随时有队列进程在等着接收事件。唯一的缺陷是,我在worker stop --d的时候,如果想同步停止队列,需要在onWorkerStop去调用一个shell脚本来kill队列进程,laravel queue本身也并没有提供一个优雅的stop方法,导致这个kill脚本很可能会执行失败,这个情况下,workerman会出现一个死循环的exit with status 9异常,不停写日志,我前面好像发过issue。或者说kill时队列里还有未完成的任务,会积累到下次重启队列才能纠错。无论哪一种,都谈不上优雅。
用 Supervisor 来监听,专门做这个的
那是最后的选择,我觉得workerman应该有方案可以达到和supervisor相同的效果
最后还是用了supervisor
我有个方案,workerman监听一个端口,并设置onClose回调。
laravel queue 进程启动后发起一个连接连workerman这个端口。
如果laravel queue 进程挂掉,那么连接也会close,workerman的onClose就会触发。
onClose触发时去检查laravel queue 是否挂掉。这样监控是最实时的,但是挺麻烦的。
我现在还采用了另一个方案,启动queue进程是永不退出的,workerman的工作进程作为守护进程来检测queue进程数量,这样有queue进程异常退出导致进程数不足时,workerman的工作进程可以补足数量。这样做可以把timer间隔设得比较大,事件推入队列也是实时的,因为随时有队列进程在等着接收事件。唯一的缺陷是,我在worker stop --d的时候,如果想同步停止队列,需要在onWorkerStop去调用一个shell脚本来kill队列进程,laravel queue本身也并没有提供一个优雅的stop方法,导致这个kill脚本很可能会执行失败,这个情况下,workerman会出现一个死循环的exit with status 9异常,不停写日志,我前面好像发过issue。或者说kill时队列里还有未完成的任务,会积累到下次重启队列才能纠错。无论哪一种,都谈不上优雅。
是否可以在onWorkerStop 里面像队列进程发送一个停止的信号,甚至可以是一个停止的队列任务(这个队列任务优先级最高),从而让队列自己退出自己
用laravel Horizon 不是更好么,动态进程数,而且进程数我觉得开你能接受的最大就行,反正没任务的时候进程在阻塞挂起,几乎不耗CPU
没关注新发布的官方扩展包,多谢了。
如果要将 Horizon 部署到一个正在运行的服务器上,应该配置一个进程监视器来监视 php artisan horizon 命令,并在它意外退出时重新启动它。
结果Horizon自身进程也需要被守护,还是没有解决问题。
当然要用supervisor守护了,它干的就是这事,我司领导不想用supervisor我才用的workerman当的进程守护工具