php散布式gearman技巧_分布式计算框架Gearman事理详解

文章目录 [+]

Gearman供应了一个通用的运用程序框架，用于将事情转移到更适宜于事情的其他机器或流程。
它许可你并行事情，负载平衡处理，并在措辞间调用函数。
它可用于从高可用性网站到传输数据库复制事宜的各种运用程序。
换句话说，它是分布式处理互换的神经系统。
关于Gearman的一些优点：

开源它是免费的！
（在这个词的两个意思中）Gearman有一个生动的开源社区，如果你须要帮助或者想贡献，很随意马虎参与进来。
担心授权？Gearman是BSD。

php散布式gearman技巧_分布式计算框架Gearman事理详解

多措辞 - 有一些措辞的接口，这个列表正在增长。
您也可以选择利用一种措辞提交事情的客户端编写异构运用程序，并在另一种措辞中实行该事情的事情职员。

（图片来自网络侵删）

灵巧 - 您不受限于任何特定的设计模式。
您可以利用您选择的任何模型快速组合分布式运用程序，这些选项之一是Map / Reduce。

快速 - Gearman有一个大略的协议和接口，用C / C ++编写的优化的，线程化的做事器可以最大限度地减少运用程序开销。

嵌入式 - 由于Gearman速率快，重量轻，适用于各种尺寸的运用。
以最小的开销引入现有的运用程序也很随意马虎。

没有单点故障 - Gearman不仅可以帮助扩展系统，而且还可以通过容错办法实现。

大小没有限定 - Gearman支持最多4gig的单个。
须要做更大的事情？没问题Gearman可以大块。

担心缩放？ - 不要担心Gearman。
克雷格的名单，Tumblr，Yelp，Etsy，...创造别人已经知道了多年。

内容正在定期更新，以是请常常查看。
如果您想理解更多信息或参与个中，您可能还想查看其他沟通形式！

Gearman如何事情？

一个Gearman驱动的运用程序由三部分组成：一个客户端，一个事情者和一个作业做事器。
客户端卖力创建要运行的作业并将其发送到作业做事器。
作业做事器将找到可以运行作业并转产生发火业的得当事情职员。
事情职员实行客户端要求的事情，并通过作业做事器向客户端发送相应。
Gearman供应您的运用程序调用的客户端和事情者API来与Gearman作业做事器（也称为gearmand）交谈，因此您不须要处理网络或作业的映射。
在内部，gearman客户端和事情者API利用TCP套接字与作业做事器进行通信。
为了更详细地阐明Gearman的事情事理，我们来看看一个大略的运用程序，它将颠倒字符串中字符的顺序。
这个例子在PHP中给出，

我们首先编写一个客户端运用程序，卖力发送作业并等待结果，以便打印出来。
它通过利用Gearman客户端API来发送一些与函数名干系的数据，在这种情形下是函数reverse。
这个代码是（为了简洁，省略了缺点处理）：

<?php// Reverse Client Code$client = new GearmanClient();$client->addServer();print $client->do(\"大众reverse\"大众, \"大众Hello World!\"大众);

此代码初始化一个客户端类，将其配置为利用带有add_server（不带参数表示利用127.0.0.1默认端口）的作业做事器，然后关照客户端API以reverse事情负载“Hello world！
” 运行该功能。
就Gearman而言，函数名称和参数是完备任意的，以是您可以发送适宜您运用程序的任何数据构造（文本或二进制文件）。
此时，Gearman客户端API将把该作业打包到一个Gearman协议数据包中，并将其发送到作业做事器以查找可以运行该reverse 功能的得当的事情职员。
现在让我们看看工人代码：

<?php// Reverse Worker Code$worker = new GearmanWorker();$worker->addServer();$worker->addFunction(\"大众reverse\"大众, function ($job) { return strrev($job->workload());});while ($worker->work());

这段代码定义了一个函数my_reverse_function，它接管一个字符串并返回该字符串的反转。
它被一个工为难刁难象用来注册一个函数，该函数reverse被设置为连接到与客户端相同确当地作业做事器。
当作业做事器吸收到要运行的作业时，它查看已经注册了该功能名称reverse的事情职员列表，并将该作业转发给个中一个空闲事情职员。
然后，Gearman事情者API接管这个要求，运行该功能my_reverse_function，并通过作业做事器将该功能的结果发送回客户端。

如您所见，客户端和事情者API（以及作业做事器）处理作业管理和网络通信，因此您可以专注于运用程序部分。
有几种不同的方法可以在Gearman中运行作业，包括异步处理和优先作业的背景。
有关详细信息，请参阅可用于各种API 的文档。

Gearman如何有用？

上面的例子看起来像是很多事情来运行一个函数，但是有很多方法可以用。
最大略的答案是，你可以利用Gearman作为用不同措辞编写的客户端和事情者之间的接口。
如果您希望PHP Web运用程序调用用C措辞编写的函数，则可以将PHP客户端API与C事情程序API合营利用，并在中间粘贴作业做事器。
当然，还有更高效的办法来做这件事（比如用C写一个PHP扩展），但是你可能须要一个PHP客户端和一个Python事情者，或者一个MySQL客户端和一个Perl事情者。
您可以轻松地稠浊和匹配任何支持的措辞界面，只须要所有运用程序都能够理解所发送的事情量。
你最喜好的措辞是不是支持？得到参与项目，对付你或者现有的Gearman开拓职员来说，在C库的顶部放置一个措辞包装可能相称随意马虎。

Gearman的另一个有用的方法是把事情代码放在一个更适宜事情的单独的机器上（或者一组机器上）。
假设您的PHP Web运用程序想要进行图像转换，但这是在Web做事器机器上运行它的太多处理。
您可以将映像发送到单独的一组事情机器上进行转换，这样负载不会影响Web做事器和其他PHP脚本的性能。
通过这样做，您也可以得到一种自然形式的负载平衡，由于作业做事器仅向闲置的事情职员发送新作业。
如果在特定机器上运行的所有事情职员都很忙，则不必担心在那里发送新事情。
这使得多查究事器的扩展非常大略：工人机器上有16个核心吗？启动你的工人的16个实例（或更多，如果他们没有CPU绑定）。
也可以无缝添加新机器来扩展您的事情池，只需启动它们，安装事情代码，并将它们连接到现有的作业做事器。

现在你可能会问如果作业做事器去世亡？您可以运行多个作业做事器，并让客户端和事情职员连接到配置的第一个可用作业做事器。
这样，如果一个事情做事器去世亡，客户端和事情职员会自动故障转移到另一个事情服你可能不想运行太多的作业做事器，但有两到三个是冗余的好主张。
左图显示了一个大略的Gearman集群的外不雅观。

从这里，您可以根据须要扩展您的客户和事情职员。
作业做事器可以轻松处理一次连接数百个客户端和事情职员。
您可以在容量许可的情形下绘制自己的物理（或虚拟）机器生产线，可能将负载分配到任意数量的机器。
有关详细利用和安装的更多细节，请参阅示例部分。

更新来。

2Gearman架构中的三个角色

client：要求的发起者，事情任务的需求方（可以是C、PHP、Java、Perl、Mysql udf等等）

Job Server：要求的调度者，卖力将client的要求转发给相应的worker（gearmand做事进程创建）

worker：要求的处理者（可以是C、PHP、Java、Perl等等）

Gearman是如何事情的？

从上图可以看出，Gearman Client API，Gearman Worker API，Gearman Job Server都是由gearman本身供应，我们在运用中只须要调用即可。
目前client与worker api都很丰富。

3Gearman的吞吐能力

经由的测试，结果如下：

系统环境：ubuntu-14.0.4 1个CPU 4核 2G内存（虚拟机）

默认启动：./gearmand -d

client.php

<?php

echo \"大众starting...\"大众, microtime(true), \"大众n\"大众;

$gmc = new GearmanClient();

$gmc->setCompleteCallBack(function($task){

//echo $task->data(), \公众n\"大众;

});

$gmc->addServer(\"大众127.0.0.1\"大众, 4730);

for ($i = 0; $i < 100000; $i++) {

$gmc->addTaskBackground(\公众reserve\"大众, \"大众just test it\公众, null, $i);

}

$gmc->runTasks();

echo \"大众end...\公众, microtime(true), \"大众n\"大众;

worker.php

<?php

$gmw = new GearmanWorker();

$gmw->addServer(\"大众127.0.0.1\"大众, 4730);

$gmw->addFunction(\"大众reserve\公众, function($job) {

if ($job->unique() == 99999) {

echo microtime(true), \公众n\公众;

}

return strrev($job->workload());

});

while($gmw->work());

启动一个job server实例：job server IP:127.0.0.1 PORT:4730

启动一个worker: php worker.php

worker注册reserve函数，将client的job字符串反转后返回。

client事情任务的为：just test it（12字节）

同步：4100/s

异步：25700/s

memcached内存准持久化的吞吐能力测试

./gearmand -d -q libmemcached —libmemcached-servers=127.0.0.1:11211

client投递100000个事情任务：16400/s

Gearman范例的支配构造

Gearman支持的特性

高可用

启动两个job server，他们是独立的做事进程，有各自的内存行列步队。
当一个job server进程涌现故障，另一个job server可以正常调度。
（worker api与client api可以完成job server故障的切换）。
在任何时候我们可以关闭某个worker，纵然那个worker正在处理事情任务（Gearman不会让正在被实行的job丢失的，由于worker在事情时与Job server是长连接，以是一旦worker发生非常，Job server能够迅速感知并重新派发这个非常worker刚才正在实行的事情）

负载均衡（附gearman协议会详细阐明）

job server并不主动分派事情任务，而是由worker从空闲状态唤醒之后到job server主动抓取事情任务。

可扩展

松耦合的接口和无状态的job，只须要启动一个worker，注册到Job server集群即可。
新加入的worker不会对现有系统有任何的影响。

分布式

gearman是分布式的任务分发框架，worker与job server，client与job server通信基于tcp的socket连接。

行列步队机制

gearman内置内存行列步队，默认情形行列步队最大容量为300W，可以配置最大支持2^32-1，即4 294 967 295。

高性能

作为Gearman的核心，Job server的是用C/C++实现的，由于只是做大略的任务派发，因此系统的瓶颈不会出在Job server上。

两种事情任务

后台事情任务Background job——时序图

由图可知，client提交完job，job server成功吸收后返回JOB_CREATED相应之后，client就断开与job server之间的链接了。
后续无论发生什么事情，client都是不关心的。
同样，job的实行结果client端也没办法通过Gearman框架得到。

一样平常事情任务Non-background job——时序图

由图可知，client端在job实行的全体过程中，与job server真个链接都是保持着的，这也给job完成后job server返回实行结果给client供应了通路。
同时，在job实行过程当中，client端还可以发起job status的查询。
当然，这须要worker真个支持的。

4关于持久化

对付行列步队持久化的问题，是一个值得考虑的问题。
持久化一定影响高性能。
gearman支持后台事情任务的持久化，支持drizzle、mysql、memcached的持久化。
对付client提交的background job，Job server除了将其放在内存行列步队中进行派发之外，还会将其持久化到外部的持久化行列步队中。
一旦Job server发生问题重启，外部持久化行列步队中的background job将会被规复到内存中，参与Job server新的派发当中。
这担保了已提交未实行的background job不会由于Job server发生非常而丢失。
并且我测试创造如果开启了持久化，那么后台事情任务会先将事情任务写到持久化介质，然后在入内存行列步队，再实行。
非后台事情任务，由于client与job server是保持长连接的状态，如果事情任务实行非常，client可以灵巧处理，以是无须持久化。

Gearman框架中的一个问题

从范例支配构造看出，两个Job server之间是没有连接的。
也便是Job server间是不共享background job的。
如果通过让两个Job server指向同一个持久化行列步队，可以让两个Job serer相互备份。
但实际上，这样是行不通的。
由于Job server只有在启动时才会将持久化行列步队中的background job转入到内存行列步队。
也便是说，Job server1如果宕机且永久不启动，Job server2一贯正常运行，那么Job server1宕机前被提交到Job server1的未被实行的background job将永久都呆在持久化行列步队中，得不到实行。
其余如果多个job server实例指向同一个持久化行列步队，同时重启多个job server实例会导致持久行列步队中的事情任务被多次载入，从而导致重复处理。

我建议的支配构造

采取memcached做后台事情任务的准持久化行列步队，最好memcached和job server在内网的不同机器。
两个机器的两个做事同时挂掉的可能性比较小，同时也担保了高性能。
而且memcached该当为两个相互独立实例，防止其上述的gearman框架中的问题。
我们可以做一个监控脚本，如果某个job server非常退出，可以重启，也最大化的担保了job server的高可用。

5关于Gearman的管理工具

目前有一个现在的管理工具，https://github.com/brianlmoon/GearmanManager，但是只支持php-5.2，不过可以自行修正支持php-5.4，我建议如果利用PHP作为worker进程，利用php-5.4以上的版本。
该工具的设计方法可以借鉴，可以比较好的管理gearman worker。

运用处景

结合linux crontab，php脚本卖力产生job，将任务分发到多台做事器周期性的并发实行。
可以取代目前我们比较多的crontab的事情任务。

邮件短信发送

异步log

跨措辞相互调用（对付密集型打算的需求，可以用C实现，PHP直接调用）

其他耗时脚本

Gearman安装（unbuntu）

下载

$>wget https://launchpadlibrarian.net/165674261/gearmand-1.1.12.tar.gz

安装依赖包

$>sudo apt-get install libboost1.55-all-dev gperf libevent libevent-dev uuid libmemcached-dev$>tar zxvf gearmand-1.1.12.tar.gz$>cd gearmand-1.1.12$>/configure --prefix=/home/phpboy/Server/gearman$>make & make install

启动

a)默认启动

$>./gearman -d

b)支持memcached准持久化

$>./gearmand -d -q libmemcached --libmemcached-servers=127.0.0.1:11211

安装php的Gearman扩展

$>wget http://pecl.php.net/get/gearman-1.1.2.tgz$>tar zxvf gearman-1.1.2.tgz#cd gearman-1.1.2$>phpize$>./configure --with-php-config=php-config$>make & make install

php client api与php worker api

可以用上面我的测试的示例

附Gearmand（job server的启动参数大略解释）

-b, –backlog=BACKLOG 连接要求行列步队的最大值-d, –daemon Daemon 守护进程化 -f, –file-descriptors=FDS 可打开的文件描述符数量 -h, –help -l, –log-file=FILE Log 日志文件-L, –listen=ADDRESS 开启监听的地址 -p, –port=PORT 开启监听的端口 -P, –pid-file=FILE File pid file -r,–protocol=PROTOCOL 利用的协议 -q, –queue-type=QUEUE 持久化行列步队类型 -t, –threads=THREADS I/O线程数量 -u, –user=USER 进程的有效用户名 libdrizzle Options: --libdrizzle-host=HOST Host of server. --libdrizzle-port=PORT Port of server. --libdrizzle-uds=UDS Unix domain socket for server. --libdrizzle-user=USER User name for authentication. --libdrizzle-password=PASSWORD Password for authentication. --libdrizzle-db=DB Database to use. --libdrizzle-table=TABLE Table to use. --libdrizzle-mysql Use MySQL protocol. libmemcached Options: --libmemcached-servers=SERVER_LIST List of Memcached servers to use. libsqlite3 Options: --libsqlite3-db=DB Database file to use. --libsqlite3-table=TABLE Table to use. libpq Options: --libpq-conninfo=STRING PostgreSQL connection information string. --libpq-table=TABLE Table to use. http Options: --http-port=PORT Port to listen on.

Gearman通信协议

总括

Gearman事情在TCP上，默认端口为4730，client与job server、worker与job server的通信都基于此tcp的socket连接。
client是事情任务的发起者，worker是可以注册处理函数的事情任务实行者，job server为事情的调度者。
协议包含要求报文与相应报文两个部分，所有发向job server的数据包（TCP报文段的数据部分）认为是要求报文，所有从job server发出的数据包（TCP报文段的数据部分）认为是相应报文。
worker或者client与job server间的通信是基于二进制数据流的，但在管理client也有基于行文本协议的通信。

要求的报文体

相应的报文体

后台事情任务Background job

一样平常事情任务Non-background job

二进制包

要求报文与相应报文是由二进制包封装。
一个二进制包由头header和可选的数据部分data组成。

header的组成

报文种别，要求报文或者相应报文，4个字节

“�REQ” 要求报文

“�RES” 相应报文

包类型，高（大）字节序（网络字节序），4个字节可能的类型有

类型值名称报文类型发送者

1 CAN_DO REQ Worker 2 CANT_DO REQ Worker 3 RESET_ABILITIES REQ Worker 4 PRE_SLEEP REQ Worker 5 (unused) - - 6 NOOP RES Worker 7 SUBMIT_JOB REQ Client 8 JOB_CREATED RES Client 9 GRAB_JOB REQ Worker 10 NO_JOB RES Worker 11 JOB_ASSIGN RES Worker 12 WORK_STATUS REQ Worker 13 WORK_COMPLETE REQ Worker 14 WORK_FAIL REQ Worker 15 GET_STATUS REQ Client 16 ECHO_REQ REQ Client/Worker 17 ECHO_RES RES Client/Worker 18 SUBMIT_JOB_BG REQ Client19 ERROR RES Client/Worker 20 STATUS_RES RES Client 21 SUBMIT_JOB_HIGH REQ Client 22 SET_CLIENT_ID REQ Worker 23 CAN_DO_TIMEOUT REQ Worker 24 ALL_YOURS REQ Worker 25 WORK_EXCEPTION REQ Worker 26 OPTION_REQ REQ Client/Worker 27 OPTION_RES RES Client/Worker 28 WORK_DATA REQ Worker 29 WORK_WARNING REQ Worker 30 GRAB_JOB_UNIQ REQ Worker 31 JOB_ASSIGN_UNIQ RES Worker 32 SUBMIT_JOB_HIGH_BG REQ Client 33 SUBMIT_JOB_LOW REQ Client 34 SUBMIT_JOB_LOW_BG REQ Client 35 SUBMIT_JOB_SCHED REQ Client 36 SUBMIT_JOB_EPOCH REQ Client

可选数据部分长度，高（大）字节序（网络字节序），4个字节，可表示的值为4294967295

数据部分，数据部分的各个部分为null字符分隔。

详细各包类型的解释

client和worker可发送要求报文

ECHO_REQ

当job server收到此包类型的要求报文时，就大略的产生一个包类型为ECHO_RES，同时将要求报文的数据部分作为相应报文的数据部分的报文。
紧张用于测试或者调试

如：

Client -> Job Server 00 52 45 51 0REQ 报文类型 00 00 00 a0 16 (Packet type: ECHO_ERQ) 00 00 00 04 4 (Packet length) 74 65 73 74 test (Workload)

ECHO_RESclient和worker可吸收相应报文

当job server相应ECHO_REQ报文时发送的包类型为ECHO_RES的相应报文

如：

Job Server -> Client 00 52 45 53 0RES 报文类型 00 00 00 a1 17 (Packet type: ECHO_ERS) 00 00 00 04 4 (Packet length) 74 65 73 74 test (Workload)

当job server发生缺点时，须要关照client或者workerERROR

client发送的要求报文：（仅能由client发送的要求报文）

SUBMIT_JOB, SUBMIT_JOB_BG,SUBMIT_JOB_HIGH, SUBMIT_JOB_HIGH_BG,SUBMIT_JOB_LOW, SUBMIT_JOB_LOW_BG

当client有一个事情任务须要运行，就会提交相应的要求报文，job server相应包类型为JOB_CREATED数据部分为job handle的相应报文。
SUBMIT_JOB为普通的事情任务，client得到状态更新及关照任务已经完成的相应；SUBMIT_JOB_BG为异步的事情任务，client不关心任务的完成情形；SUBMIT_JOB_HIGH为高优先级的事情任务，SUBMIT_JOB_HIGH_BG为高优先级的异步任务；SUBMIT_JOB_LOW为低优先级的事情任务，SUBMIT_JOB_LOW_BG为低优先级的异步任务。

如：

1 2 3 4 5 6 7 8 9 10 11 12 13

Client -> Job Server 00 52 45 51 0REQ (报文类型) 00 00 00 07 7 (Packet type: SUBMIT_JOB) 00 00 00 0d 13 (Packet length) 72 65 76 65 72 73 65 00 reverse0 (Function) 00 � (Unique ID) 74 65 73 74 test (Workload)

SUBMIT_JOB_SCHED

和SUBMIT_JOB_BG类似，此类型的事情任务不会立即实行，而在设置的某个韶光运行。

如：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Client -> Job Server 00 52 45 51 0REQ (报文类型) 00 00 00 23 35 (Packet type: SUBMIT_JOB_SCHED) 00 00 00 0d 13 (Packet length) 72 65 76 65 72 73 65 00 reverse0 (Function) 00 � (Unique ID) 01 � (minute 0-59) 01 � (hour 0-23) 01 � (day of month 1-31) 01 � (day of month 1-12) 01 � (day of week 0-6) 74 65 73 74 test (Workload)

SUBMIT_JOB_EPOCH

和SUBMIT_JOB_SCHED浸染一样，只是将设置的韶光定为了uinx韶光戳GET_STATUS获取某个事情任务实行的状态信息

OPTION_REQ

设置client与job server连接的选项

client获取的相应报文：

JOB_CREATED相应包类型为SUBMIT_JOB的要求报文，数据部分为job handle

WORK_DATA, WORK_WARNING, WORK_STATUS, WORK_COMPLETE,WORK_FAIL, WORK_EXCEPTION

对付后台运行的事情任务，任务实行信息可以通过包类型为上面的值来查看。

STATUS_RES

相应包类型为GET_STATUS的要求报文，常日用来查看一个后台事情任务是否已经完成，以及完成的百分比。

OPTION_RES

相应包类型为OPTION_REQ的要求报文

worker发送的要求报文：

CAN_DO

关照job server可以实行给定的function name的任务，此worker将会放到一个链表，当job server收到一个function name的事情任务时，worker为被唤醒。

CAN_DO_TIMEOUT

和CAN_DO类似，只是针对给定的function_name的任务设置了一个超时时间。

CANT_DO

worker关照job server已经不能实行给定的function name的任务

RESET_ABILITIES

worker关照job server不能实行任何function name的任务

PRE_SLEEP

worker关照job server它将进入sleep阶段，而之后此worker会被包类型为NOOP的相应报文唤醒。

GRAB_JOB

worker向job server抓取事情任务，job server将会相应NO_JOB或者JOB_ASSIG

NGRAB_JOB_UNIQ

和GRAB_JOB类似，但是job server在有事情任务时将会相应JOB_ASSIGN_UNIQ

WORK_DATA

worker要求报文的数据部分更新client

WORK_WARNING

worker要求报文代表一个warning，它该当被对待为一个WARNING

WORK_STATU

Sworker更新某个job handle的事情状态，job server该当储存这些信息，以便相应之后client的GET_STATUS要求

WORK_COMPLETE

关照job server及所有连接的client，数据部分为返回给client的数据

WORK_FAIL

关照job server及所有连接的client，事情任务实行失落败

WORK_EXCEPTION

关照job server及所有连接的client，事情任务实行失落败并给出相应的非常

SET_CLIENT_ID

设置worker ID，从而job server的掌握台及报告命令可以标识各个worker，数据部分为worker实例的标识

ALL_YOURS

暂未实现

worker获取的相应报文：

NOOP

job server唤醒sleep的worker，以便可以开始抓取事情任务

NO_JOB

job server相应GRAB_JOB的要求，关照worker没有等待实行的事情任务

JOB_ASSIGN

job server相应GRAB_JOB的要求，关照worker有须要实行的事情任务

JOB_ASSIGN_UNIQ

job server相应GRAB_JOB_UNIQ的要求，和JOB_ASSIGN一样，只是为client通报了一个唯一标识

基于上述的协议描述一个完全的例子

worker注册可以实行的事情任务

Worker -> Job Server

1 2 3 4 5 6 7

00 52 45 51 0REQ (Magic) 00 00 00 01 1 (Packet type: CAN_DO) 00 00 00 07 7 (Packet length) 72 65 76 65 72 73 65 reverse (Function)

worker检测或者抓取事情任务

1 2 3 4 5 6 7

Worker -> Job Server 00 52 45 51 0REQ (Magic) 00 00 00 09 9 (Packet type: GRAB_JOB) 00 00 00 00 0 (Packet length)

job server相应worker的抓取事情（没有事情任务）

1 2 3 4 5

00 52 45 53 0RES (Magic) 00 00 00 0a 10 (Packet type: NO_JOB) 00 00 00 00 0 (Packet length)

worker关照job server开始sleep

1 2 3 4 5

00 52 45 51 0REQ (Magic) 00 00 00 04 4 (Packet type: PRE_SLEEP) 00 00 00 00 0 (Packet length)

client提交事情任务

1 2 3 4 5 6 7 8 9 10 11 12 13

Client -> Job Server 00 52 45 51 0REQ (Magic) 00 00 00 07 7 (Packet type: SUBMIT_JOB) 00 00 00 0d 13 (Packet length) 72 65 76 65 72 73 65 00 reverse0 (Function) 00 � (Unique ID) 74 65 73 74 test (Workload)

job server相应client的SUBMIT_JOB要求，返回job handle

1 2 3 4 5 6 7

00 52 45 53 0RES (Magic) 00 00 00 08 8 (Packet type: JOB_CREATED) 00 00 00 07 7 (Packet length) 48 3a 6c 61 70 3a 31 H:lap:1 (Job handle)

job server唤醒worker

1 2 3 4 5 6 7

Job Server -> Worker 00 52 45 53 0RES (Magic) 00 00 00 06 6 (Packet type: NOOP) 00 00 00 00 0 (Packet length)

worker的抓取事情任务

Worker -> Job Server

00 52 45 51 \0REQ (Magic)

00 00 00 09 9 (Packet type: GRAB_JOB)

00 00 00 00 0 (Packet length)

job server分配事情任务给worker