Swoft源码之Swoole和Swoft的分析
这篇文章给大家分享的内容是关于swoft 源码剖析之swoole和swoft的一些介绍(task投递/定时任务篇),有一定的参考价值,有需要的朋友可以参考一下。
前言
swoft
的任务功能基于swoole
的task机制
,或者说swoft
的task
机制本质就是对swoole
的task机制
的封装和加强。
任务投递
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
|
任务投递task::deliver()
将调用参数打包后根据$type
参数通过swoole
的$server->taskco()
或$server->task()
接口投递到task进程
。task
本身始终是同步执行的,$type
仅仅影响投递这一操作的行为,task::type_async
对应的$server->task()
是异步投递,task::deliver()
调用后马上返回;task::type_co
对应的$server->taskco()
是协程投递,投递后让出协程控制,任务完成或执行超时后task::deliver()
才从协程返回。
任务执行
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
|
此处是swoole.ontask
的事件回调,其职责仅仅是将将worker
进程投递来的打包后的数据转发给taskexecutor
。
swoole
的task
机制的本质是worker进程
将耗时任务投递给同步的task进程
(又名taskworker
)处理,所以swoole.ontask
的事件回调是在task进程
中执行的。上文说过,worker进程
是你大部分http
服务代码执行的环境,但是从taskeventlistener.ontask()
方法开始,代码的执行环境都是task进程
,也就是说,taskexecutor
和具体的taskbean
都是执行在task进程
中的。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
|
任务执行思路很简单,将worker进程
发过来的数据解包还原成原来的调用参数,根据$name
参数找到对应的taskbean
并调用其对应的task()
方法。其中taskbean
使用类级别注解@task(name="taskname")
或者@task("taskname")
声明。
值得一提的一点是,@task
注解除了name
属性,还有一个coroutine
属性,上述代码会根据该参数选择使用协程的runcotask()
或者同步的runsynctask()
执行task
。但是由于而且由于swoole
的task进程
的执行是完全同步的,不支持协程,所以目前版本请该参数不要配置为true
。同样的在taskbean
中编写的任务代码必须的同步阻塞的或者是要能根据环境自动将异步非阻塞和协程降级为同步阻塞的
从process中投递任务
前面我们提到:
swoole
的task
机制的本质是worker进程
将耗时任务投递给同步的task进程
(又名taskworker
)处理。
换句话说,swoole
的$server->taskco()
或$server->task()
都只能在worker进程
中使用。
这个限制大大的限制了使用场景。 如何能够为了能够在process
中投递任务呢?swoft
为了绕过这个限制提供了task::deliverbyprocess()
方法。其实现原理也很简单,通过swoole
的$server->sendmessage()
方法将调用信息从process
中投递到worker进程
中,然后由worker进程替其投递到task进程
当中,相关代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
数据打包后使用$server->sendmessage()
投递给worker
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
$server->sendmessage
后,worker进程
收到数据时会触发一个swoole.pipemessage
事件的回调,swoft
会将其转换成自己的swoft.pipemessage
事件并触发.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
swoft.pipemessage
事件最终由pipemessagelistener
处理。在相关的监听其中,如果发现swoft.pipemessage
事件由task::deliverbyprocess()
产生的,worker进程
会替其执行一次task::deliver()
,最终将任务数据投递到taskworker进程
中。
一道简单的回顾练习:从task::deliverbyprocess()
到某taskbean
最终执行任务,经历了哪些进程,而调用链的哪些部分又分别是在哪些进程中执行?
从command进程或其子进程中投递任务
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
对于command
进程的任务投递,情况会更复杂一点。
上文提到的process
,其往往衍生于http/rpc
服务,作为同一个manager
的子孙进程,他们能够拿到swoole\server
的句柄变量,从而通过$server->sendmessage()
,$server->task()
等方法进行任务投递。
但在swoft
的体系中,还有一个十分路人的角色: command
。command
的进程从shell
或cronb
独立启动,和http/rpc
服务相关的进程没有亲缘关系。因此command
进程以及从command
中启动的process
进程是没有办法拿到swoole\server
的调用句柄直接通过unixsocket
进行任务投递的。
为了为这种进程提供任务投递支持,swoft
利用了swoole
的task进程
的一个特殊功能----消息队列。
同一个项目中command
和http\rpcserver
通过约定一个message_queue_key
获取到系统内核中的同一条消息队列,然后comand
进程就可以通过该消息队列向task进程
投递任务了。
该机制没有提供对外的公开方法,仅仅被包含在task::deliver()
方法中,swoft
会根据当前环境隐式切换投递方式。但该消息队列的实现依赖semaphore
拓展,如果你想使用,需要在编译php
时加上--enable-sysvmsg
参数。
定时任务
除了手动执行的普通任务,swoft
还提供了精度为秒的定时任务功能用来在项目中替代linux的crontab
功能.
swoft
用两个前置process
---任务计划进程:crontimerprocess
和任务执行进程cronexecprocess
,和两张内存数据表-----runtimetable
(任务(配置)表)origintable
((任务)执行表)用于定时任务的管理调度。
两张表的每行记录的结构如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
此处为何要使用swoole的内存table?
swoft
的的定时任务管理是分别由 任务计划进程 和 任务执行进程 进程负责的。两个进程的运行共同管理定时任务,如果使用进程间独立的array()
等结构,两个进程必然需要频繁的进程间通信。而使用跨进程的table
(本文的table
,除非特别说明,都指swoole
的swoole\table
结构)直接进行进程间数据共享,不仅性能高,操作简单 还解耦了两个进程。
为了table
能够在两个进程间共同使用,table
必须在swoole server
启动前创建并分配内存。具体代码在swoft\task\bootstrap\listeners->onbeforestart()
中,比较简单,有兴趣的可以自行阅读。
背景介绍完了,我们来看看这两个定时任务进程的行为
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
crontimerprocess
是swoft
的定时任务调度进程,其核心方法是crontab->initruntimetabledata()
。
该进程使用了swoole
的定时器功能,通过swoole\timer
在每分钟首秒时执行的回调,crontimerprocess
每次被唤醒后都会遍历任务表计算出当前这一分钟内的60秒分别需要执行的任务清单,写入执行表并标记为 未执行。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
|
cronexecprocess
作为定时任务的执行者,通过swoole\timer
每0.5s
唤醒自身一次,然后把 执行表
遍历一次,挑选当下需要执行的任务,通过sendmessage()
投递出去并更新该 任务执行表中的状态。
该执行进程只负责任务的投递,任务的实际实际执行仍然在task进程
中由taskexecutor
处理。
定时任务的宏观执行情况如下: