CN105912402B

CN105912402B - 一种基于Actor模型的调度方法及装置

Info

Publication number: CN105912402B
Application number: CN201610219998.3A
Authority: CN
Inventors: 许泽文; 孟祥梯; 袁振华; 万留美; 穆良源
Original assignee: Shenzhen Eybond Co Ltd
Current assignee: Shenzhen Eybond Co Ltd
Priority date: 2016-04-11
Filing date: 2016-04-11
Publication date: 2019-04-02
Anticipated expiration: 2036-04-11
Also published as: CN105912402A

Abstract

本发明实施例公开了一种基于Actor模型的调度方法及装置，用于简化消息处理流程，提高开发效率。本发明实施例方法包括：在启动Actor时，对所述Actor的阻塞类型进行判断，其中，所述Actor的阻塞类型包括不可阻塞的Actor和可阻塞的Actor；若所述Actor为不可阻塞的Actor，则将所述Actor的消息存入第一线程池的某一IO多路复用器线程中；若所述Actor为可阻塞的Actor，则将所述Actor的消息存入第二线程池的消息队列中；其中，所有不可阻塞的Actor共享第一线程池，所述第一线程池包括预设数量的IO多路复用器线程；其中，每个可阻塞的Actor独占一个第二线程池，且每个可阻塞的Actor在对应的第二线程池中拥有独立的消息队列。

Description

一种基于Actor模型的调度方法及装置

技术领域

本发明涉及通信领域，尤其涉及一种基于Actor模型的调度方法及装置。

背景技术

Actor模型是著名的并发计算模型，目前其已成为研制并发面向对象语言的一种重要的基础模型。Actor模型的一个基本认知是：在Actor模型中所有对象都是Actor，也就是Actor是Actor模型的原子单位，不同的Actor之间通过消息进行通讯。

目前，支持Actor模型的语言和开发库主要包括Erlang、Scala、基于Scala和 Java的Akka以及基于C++11的libcaf等，它们使用不同的Actor调度机制，如Erlang基于轻量级线程与邮箱（Mailbox），Scala、Akka和libcaf则基于单一线程池与邮箱，然而，使用单一线程池与邮箱也带来一些问题：

一是单一线程池机制不允许任何置于其中的Actor进行消息处理时阻塞，因为只要某一调度线程上有一个Actor处于阻塞状态，都将导致整个调度系统停滞。

二是为每个Actor生成一个邮箱的消息传递机制成本偏高，因为需要为每个Actor创建一个消息队列，且需要保证其在并发操作时的安全性；而且在一些网络通信场景中，需要申请一段内存将收到的报文拷贝于要发往邮箱的消息中，增加了内存占用率。

发明内容

本发明实施例提供了一种可简化消息处理流程，提高开发效率的基于Actor模型的调度方法。

本发明实施例的第一方面提供一种基于Actor模型的调度方法，包括：在启动Actor时，

对所述Actor的阻塞类型进行判断，其中，所述Actor的阻塞类型包括不可阻塞的Actor和可阻塞的Actor；

若所述Actor为不可阻塞的Actor，则将所述Actor的消息存入第一线程池的某一IO多路复用器线程中；

若所述Actor为可阻塞的Actor，则将所述Actor的消息存入第二线程池的消息队列中；

其中，所有不可阻塞的Actor共享第一线程池，所述第一线程池包括预设数量的IO多路复用器线程；

其中，每个可阻塞的Actor独占一个第二线程池，且每个可阻塞的Actor在对应的第二线程池中拥有独立的消息队列。

可选地，在所述对Actor的阻塞类型进行判断之前，所述方法还包括：

在创建所述Actor时，为所述Actor分配线程标识；

则所述对Actor的阻塞类型进行判断包括：

若所述Actor的线程标识为第一标识，则确定所述Actor为不可阻塞的Actor，若所述Actor的线程标识为第二标识，则确定所述Actor为可阻塞的Actor。

可选地，所述为所述Actor分配线程标识包括：

确定所述Actor的事件类型；

根据所述事件类型为所述Actor分配线程标识。

可选地，所述根据所述事件类型为所述Actor分配线程标识包括：

若所述Actor基于网络连接事件产生，则为所述Actor分配第一标识；

若所述Actor基于同步的数据库访问事件或同步的网络RPC调用事件产生，则为所述Actor分配第二标识。

可选地，所述Actor的消息由Lambda表达式描述。

可选地，所述Lambda表达式由future函数传递。

本发明实施例第二方面提供了一种基于Actor模型的调度装置，包括：

判断单元，用于在启动Actor时，对所述Actor的阻塞类型进行判断，其中，所述Actor的阻塞类型包括不可阻塞的Actor和可阻塞的Actor；

第一处理单元，用于若所述Actor为不可阻塞的Actor，则将所述Actor的消息存入第一线程池的某一IO多路复用器线程中；

第二处理单元，用于若所述Actor为可阻塞的Actor，则将所述Actor的消息存入第二线程池的消息队列中；

可选地，所述装置还包括：

分配单元，用于在创建所述Actor时，为所述Actor分配线程标识；

所述判断单元，具体用于若所述Actor的线程标识为第一标识，则确定所述Actor为不可阻塞的Actor，若所述Actor的线程标识为第二标识，则确定所述Actor为可阻塞的Actor。

可选地，所述分配单元包括：

确定模块，用于在创建所述Actor时，确定所述Actor的事件类型；

分配模块，用于根据所述事件类型为所述Actor分配线程标识。

可选地，所述确定模块，具体用于若所述Actor基于网络连接事件产生，则为所述Actor分配第一标识；若所述Actor基于同步的数据库访问事件或同步的网络RPC调用事件产生，则为所述Actor分配第二标识。

可选地，所述Actor的消息由Lambda表达式描述。

可选地，所述Lambda表达式由future函数传递。

本发明实施例提供的技术方案中，所有不可阻塞的Actor共享第一线程池，该第一线程池包括预设数量的IO多路复用器线程；每个可阻塞的Actor独占一个第二线程池，且每个可阻塞的Actor在对应的第二线程池中拥有独立的消息队列；在启动Actor时，首先对Actor的阻塞类型进行判断，以确定该Actor是不可阻塞的Actor还是可阻塞的Actor，若该Actor为不可阻塞的Actor，则将该Actor的消息存入第一线程池的某一IO多路复用器线程中，由该IO多路复用器线程管理，若该Actor为可阻塞的Actor，则将该Actor的消息存入第二线程池的消息队列中，由第二线程池的某个线程取出并执行。因此相对于现有技术，本发明实施例可将Actor进行阻塞类型分类，并为不同阻塞类型的Actor分配不同性质的线程池，以便简化消息处理流程，减少代码量，进而提高开发效率。

附图说明

图1为本发明实施例中服务器的架构示意图；

图2为本发明实施例中一种基于Actor模型的调度方法一个实施例示意图；

图3为本发明实施例中一种基于Actor模型的调度方法另一实施例示意图；

图4为IO多路复用器上的事件处理流程图；

图5为Actor的future函数内部处理流程图；

图6为Actor在执行并行计算时的示意图；

图7为本发明实施例中一种基于Actor模型的调度装置一个实施例示意图；

图8为本发明实施例中一种基于Actor模型的调度装置另一实施例示意图。

具体实施方式

本发明实施例提供了一种基于Actor模型的调度方法及装置，用于简化消息处理流程，提高开发效率，以下分别进行详细说明。

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，本发明实施例主要应用于服务器，特别是并发实时通信服务器。请参阅图1，为本发明实施例中服务器的架构示意图，其中，服务器监听端口用于与客户端通信，为actor服务的线程池包括一个第一线程池和一个或多个第二线程池。

下面分别对第一线程池和第二线程池进行介绍：

在本实施例中，第一线程池为多个Actor服务，该多个Actor基于一个固定线程数量的该第一线程池调度。具体地，第一线程池包括多个多路复用器线程，其中多路复用器线程是指每个线程都有一个IO多路复用器，且线程通常堵塞在IO多路复用器上（如Linux平台上epoll_wait函数），等待网络连接或报文和基于管道(PIPE)的线程唤醒报文。而且，第一线程池中的每个线程都有一个管道（PIPE），且将只读端（Read-End）置入自身的IO多路复用器，并关注读事件，只写端（Write-End）则被用于在必要时由其它线程（线程上有Actor消息到来时）写入一个字节来唤醒此线程。在实施例中，第一线程池中的每个线程可能拥有不同数量的Actor，且每个线程都有一个消息队列，由该线程上的所有Actor共享。

在本实施例中，一个第二线程池仅为一个Actor服务，该Actor被自己的线程池调度，且该Actor在该第二线程池中拥有独立的消息队列。在实际应用过程中，第二线程池中的线程数量在该Actor创建时指定，当该Actor的第二线程池中的线程数量大于1时，该Actor的消息处理是抢占式和并行的。

请参阅图1，本发明实施例中一种基于Actor模型的调度方法一个实施例包括：

201、在启动Actor时，对Actor的阻塞类型进行判断；

其中，该Actor的阻塞类型包括不可阻塞的Actor和可阻塞的Actor。在本实施例中，阻塞是指IO等待或放弃CPU(如调用sleep函数)。

202、若该Actor为不可阻塞的Actor，则将该Actor的消息存入第一线程池的某一IO多路复用器线程中；

在本实施例中，若该Actor为不可阻塞的Actor，则调用第一线程池为该Actor服务，并由第一线程池的某一IO多路复用器线程管理，下面对某一IO多路复用器线程如何进行消息处理进行简单介绍：当Actor的消息被存入某一IO多路复用器线程时，首先将该IO多路复用器线程与当前线程进行比较，若是同一线程，则直接进行消息处理，若不是同一线程，则将消息存入该IO多路复用器线程的消息队列中，同时向该线程持有的管道只写端（Write-End）写入一个字节，以唤醒此线程，当线程被唤醒时将取出消息并执行。

203、若该Actor为可阻塞的Actor，则将该Actor的消息存入第二线程池的消息队列中；

在本实施例中，若该Actor为可阻塞的Actor，则直接将该Actor的消息存入第二线程池的消息队列中，并由第一线程池中的某个线程取出并执行。

在图2所示实施例的基础上，下面进一步描述如何对Actor的阻塞类型进行判断，请参阅图3，本发明实施例中一种基于Actor模型的调度方法的另一实施例包括：

301、在创建Actor时，确定Actor的事件类型；

在本实施例中，Actor的事件类型是指Actor是基于哪种类型的事件产生的，例如，TCP连接到来事件等。

302、根据事件类型为该Actor分配线程标识；

在本实施例，Actor的事件类型不同，则Actor的阻塞类型也可能不同。

303、在启动Actor时，根据线程标识对Actor的阻塞类型进行判断；

下面详细描述如何根据线程标识对Actor的阻塞类型进行判断：

若该Actor的线程标识为第一标识，若是，则确定该Actor为不可阻塞的Actor，若该Actor的线程标识为第二标识，则确定该Actor为可阻塞的Actor。

例如，在实际应用过程中，第一线程池的每个线程都有一个唯一标识，从0至（n-1），其中，n表示线程总数。例如，第一线程池中有4个线程，则该4个线程的线程标识分别为0、1、2、3。而第二线程池的线程的线程标识固定为-1。由此，可根据线程标识来识别Actor的阻塞类型。

可以看出，在本实施例中，Actor的事件类型决定了Actor的阻塞类型，而在启动Actor时，是依据Actor过程中分配线程标识来识别Actor的阻塞类型的。

在本实施例中，如何Actor的事件类型确定Actor的阻塞类型可以根据实际需要制定相应的策略，例如，若Actor基于网络连接事件产生，则确定Actor的阻塞类型为不可阻塞的Actor，并为Actor分配第一标识；若Actor基于同步的数据库访问事件或同步的网络RPC调用事件产生，则确定Actor的阻塞类型为可阻塞的Actor，并为Actor分配第二标识。

304、若该Actor为不可阻塞的Actor，则将该Actor的消息存入第一线程池的某一IO多路复用器线程中；

在本实施例中，若该Actor为不可阻塞的Actor，则调用第一线程池为该Actor服务，并由第一线程池的某一IO多路复用器线程管理，下面对某一IO多路复用器线程如何进行消息处理进行简单介绍：当Actor的消息被存入某一IO多路复用器线程时，首先将该IO多路复用器线程与当前线程进行比较，若是同一线程，则直接进行消息处理，若不是同一线程，则将消息存入该IO多路复用器线程的消息队列中，同时向该线程持有的管道只写端（Write-End）写入一个字节，以唤醒此线程，当线程被唤醒时将取出消息并执行。具体地，请参见图4，为IO多路复用器上的事件处理流程。一个IO多路复用器上可能有三种事件：

1）、TCP连接到来事件。当此事件类型的事件到来时，将生成一个不可阻塞的Actor，且为其分配一个线程标识（不一定是当前线程的标识），再将其添加到目标线程的Actor列表（散列表）中；同时在目标线程上关注此TCP连接上的读事件。

2）、管道上的读事件。当此事件类型的事件到来时，表示当前线程的消息队列中至少有一个消息（即图4中的Lambda表达式），当前线程会在队列上反复迭代并执行取出的每个消息，直到消息队列为空。

3)、TCP连接上的读事件。当此事件类型的事件到来时，根据连接描述字（FileDescriptor）返回对应的Actor，然后读出TCP缓冲区的报文。如果报文可组成一条完整的业务消息，则交由Actor的业务处理函数进行处理。

305、若该Actor为可阻塞的Actor，则将该Actor的消息存入第二线程池的消息队列中；

在本实施例中，Actor的消息由Lambda表达式描述，所有Actor之间的通信均依赖该Lambda。在本实施例中，每个Actor都拥有一个名为“future”的函数，所有Lambda表达式都通过该future函数传递。具体请参见图5，为Actor的future函数内部处理流程图，其中，描述了future函数的内部实现机制：当调用一个Actor的future函数时，首先判断该Actor的线程标识，如果该线程标识小于0，则它是一个可阻塞的Actor，因此，直接将传入future函数的Lambda表达式push到它的消息队列，由第二线程池中的某个线程取出并执行。如果该线程标识大于等于0，则它是一个不可阻塞的Actor，且由某个IO多路复用器线程所管理，因此，可通过线程标识返回对应的IO多路复用器线程，并将其与当前线程相比较，如果是同一个线程，则直接执行传入future函数的Lambda表达式；否则将Lambda表达式push到返回的IO多路复用器线程的消息队列中，同时向此线程持有的管道只写端（Write-End）写入一个字节，以唤醒此线程，当线程被唤醒时将取出Lambda表达式并执行。

可选地，future函数的C++11实现方案可以包括：

void Actor::future(function<void()> cb)

{

if (this->wk == -1) /* 这是一个可阻塞的Actor. */

{

actor_future* f = new actor_future();

f->cb = cb;

((ActorBlocking*) this)->push(f); /* 缓存到消息队列，等待调度. */

return;

}

if (this->wk == Lx:: getCurrentWorkerIndex ()) /* 目标Actor与当前线程(代码运行时的线程)标识相同. */

cb(); /* 直接执行. */

else

{

actor_future* f = new actor_future();

f->cb = cb;

Lx::wks[this->wk].push(f); /* 缓存到消息队列，等待调度. */

}

可选地，future函数的Java8实现方案可以包括：

public void future(Consumer<Void> c)

{

if (this.wk == -1)

{

((ActorBlocking) this).push(c);

return;

}

if (this.wk == Tsc.getCurrentWorkerIndex())

c.accept(null);

else

Tsc.wks[this.wk].push(c);

}

需要说明的是，本发明实施例中的一种基于Actor模型的调度方法可以应用于多种Actor通信应用场景，请参见图6，是Actor在执行并行计算时的示意图，下面以图6为例对本发明实施例中的一种基于Actor模型的调度方法的Actor通信应用场景进行举例说明。在图6中，4个CPU（或一台4核CPU的服务器）中，每个CPU上具有一个IO多路复用器，每个IO多路复用器下辖有不同数量的不可阻塞的Actor。其中，不同的Actor之间通过future函数进行通信，这其中包括同一个IO多路复用器下的两个Actor之间、不同IO多路复用器下的两个Actor之间、某个IO多路复用器下的Actor与某个可阻塞的Actor之间这三种Actor通信应用场景。

为了便于理解，下面以用户登录应用场景为例，对本发明实施例中的一种基于Actor模型的调度方法进行详细说明：

在应用场景中，用户登录主要流程包括：

用户在客户端输入用户名、密码，点击登录按钮；

服务器收到上述信息后，尝试从数据库同步查询，得出登录成功与否的结果，并最终返回结果给客户端。

具体流程可分解如下：

A）客户端与服务器之间建立TCP连接。服务器将会生成一个不可阻塞的Actor，命名为UserActor。

B）客户端发送用户名、密码寻求登录。这个消息被包装成一个对象，命名为LoginReq。

C）进入用户消息处理函数，函数命名为UserMsg::user_login_request。

代码实现如下：

void UserMsg::user_login_request(UserActor* actor, LoginReq* request)

{

Db* db = this->getDb();

db->future([db, actor, request]

{

LoginRsp* response = new LoginRsp();

if(db->user_login(request->usr(), request->pwd()))

response->set_rsp("login ok");

else

response->set_rsp("login fail");

actor->future([actor, response]

{

actor->send(response);

});

}

在上述代码实现中，首先从进程中获得一个Db对象指针，这是一个可阻塞的Actor，接着调用它的future函数（传递了一个捕获了三个参数（db，actor，request）的Lambda表达式）。一旦该Lambda表达式被调度（由Db对象内部的线程池），便开始执行db->user_login（前往数据库查询用户名密码是否匹配）阻塞函数。当结果返回后，再调用UserActor的future函数将消息发送给客户端。

需要说明的是，基于本发明实施例中的Actor调度策略，函数UserMsg::user_login_request是最早执行完成的，因此它不会使当前IO多路复用器线程阻塞；其次是db->future函数，它将Lambda表达式push到自己的消息队列后立即返回；最后是actor->future函数，它的Lambda表达式由UserActor所在的IO多路复用器线程执行。由此可以看出，本发明的一种面向”future”的编程风格具有直观（无回调函数）、天然的并行（有效利用多核）、代码量更少、更易阅读的优点。

上面对本发明实施例中的一种基于Actor模型的调度方法进行了描述，下面对本发明实施例中的一种基于Actor模型的调度装置进行描述，请参阅图7，本发明实施例中一种基于Actor模型的调度装置一个实施例包括：

判断单元701，用于在启动Actor时，对所述Actor的阻塞类型进行判断，其中，所述Actor的阻塞类型包括不可阻塞的Actor和可阻塞的Actor；

第一处理单元702，用于若所述Actor为不可阻塞的Actor，则将所述Actor的消息存入第一线程池的某一IO多路复用器线程中；

第二处理单元703，用于若所述Actor为可阻塞的Actor，则将所述Actor的消息存入第二线程池的消息队列中；

本发明实施例提供的技术方案中，所有不可阻塞的Actor共享第一线程池，该第一线程池包括预设数量的IO多路复用器线程；每个可阻塞的Actor独占一个第二线程池，且每个可阻塞的Actor在对应的第二线程池中拥有独立的消息队列；在启动Actor时，首先由第一处理单元702对Actor的阻塞类型进行判断，以确定该Actor是不可阻塞的Actor还是可阻塞的Actor，若该Actor为不可阻塞的Actor，则由第二处理单元703将该Actor的消息存入第一线程池的某一IO多路复用器线程中，由该IO多路复用器线程管理，若该Actor为可阻塞的Actor，则由第二处理单元703将该Actor的消息存入第二线程池的消息队列中，由第二线程池的某个线程取出并执行。因此相对于现有技术，本发明实施例可将Actor进行阻塞类型分类，并为不同阻塞类型的Actor分配不同性质的线程池，以便简化消息处理流程，减少代码量，进而提高开发效率。

在图7所示实施例的基础上，下面进一步描述基于Actor模型的调度装置如何对Actor的阻塞类型进行判断，请参阅图8，本发明实施例中一种基于Actor模型的调度装置的另一实施例包括：

判断单元801，用于在启动Actor时，对所述Actor的阻塞类型进行判断，其中，所述Actor的阻塞类型包括不可阻塞的Actor和可阻塞的Actor；

第一处理单元802，用于若所述Actor为不可阻塞的Actor，则将所述Actor的消息存入第一线程池的某一IO多路复用器线程中；

第二处理单元803，用于若所述Actor为可阻塞的Actor，则将所述Actor的消息存入第二线程池的消息队列中；

在本实施例中，所述装置还包括：

分配单元804，用于在创建所述Actor时，为所述Actor分配线程标识；

所述判断单元801，具体用于若所述Actor的线程标识为第一标识，则确定所述Actor为不可阻塞的Actor，若所述Actor的线程标识为第二标识，则确定所述Actor为可阻塞的Actor。

可选地，所述分配单元804包括：

确定模块8041，用于在创建所述Actor时，确定所述Actor的事件类型；

分配模块8042，用于根据所述事件类型为所述Actor分配线程标识。

可选地，所述确定模块8041，具体用于若所述Actor基于网络连接事件产生，则为所述Actor分配第一标识；若所述Actor基于同步的数据库访问事件或同步的网络RPC调用事件产生，则为所述Actor分配第二标识。

可选地，所述Actor的消息由Lambda表达式描述。

可选地，所述Lambda表达式由future函数传递。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

1.一种基于Actor模型的调度方法，其特征在于，包括：在启动Actor时，

2.如权利要求1所述的基于Actor模型的调度方法，其特征在于，在所述对Actor的阻塞类型进行判断之前，所述方法还包括：

在创建所述Actor时，为所述Actor分配线程标识；

则所述对Actor的阻塞类型进行判断包括：

3.如权利要求2所述的基于Actor模型的调度方法，其特征在于，所述为所述Actor分配线程标识包括：

确定所述Actor的事件类型；

根据所述事件类型为所述Actor分配线程标识。

4.如权利要求3所述的基于Actor模型的调度方法，其特征在于，所述根据所述事件类型为所述Actor分配线程标识包括：

5.如权利要求1至4中任意一项所述的基于Actor模型的调度方法，其特征在于，所述Actor的消息由Lambda表达式描述。

6.如权利要求5所述的基于Actor模型的调度方法，其特征在于，所述Lambda表达式由future函数传递。

7.一种基于Actor模型的调度装置，其特征在于，包括：

8.如权利要求7所述的基于Actor模型的调度装置，其特征在于，所述装置还包括：

9.如权利要求8所述的基于Actor模型的调度装置，其特征在于，所述分配单元包括：

10.如权利要求9所述的基于Actor模型的调度装置，其特征在于，

所述确定模块，具体用于若所述Actor基于网络连接事件产生，则为所述Actor分配第一标识；若所述Actor基于同步的数据库访问事件或同步的网络RPC调用事件产生，则为所述Actor分配第二标识。

11.如权利要求7至10中任意一项所述的基于Actor模型的调度装置，其特征在于，所述Actor的消息由Lambda表达式描述。

12.如权利要求11所述的基于Actor模型的调度装置，其特征在于，所述Lambda表达式由future函数传递。