演员模型：一个演员需要另一个演员的信息

参与者 A 可以通过向参与者 B 发送请求来请求信息，但响应将以消息形式返回，参与者 A 将在未来某个时刻收到该消息。有两种方法可以保存这些信息：

1. Actor A 可以在内部存储信息以等待该响应。

2. Actor A 可以将信息附加到它发送给 Actor B 的消息中，并且 Actor B 返回该上下文（否则它会忽略）。

当Actor A从Actor B那里得到信息后，它就可以继续处理了。

这是第一种实现风格的示例，使用 Thespian Python 演员库 ( http://thespianpy.com )：

class ActorA(Actor):

    def __init__(self, *args, **kw):
        super(ActorA, self).__init__(args, kw)
        self.datalist = []

    def receiveMessage(self, msg, sender):

        if isinstance(msg, ActorAddress):
            self.actorB = msg

        elif isinstance(msg, WorkRequest):
            x = got_some_data(msg)
            self.datalist.append(x)
            self.send(self.actorB, NeedInfo())

        elif isinstance(msg, Info):
            x = self.datalist.pop()
            process_data(x, msg)

class ActorB(Actor):

    def receiveMessage(self, msg, sender):

        if isinstance(msg, NeedInfo):
            i = get_info(msg)
            self.send(sender, i)

上面显示了将工作内部存储到actor的基本功能，稍后继续。有几个考虑：

• 如果要存储多个数据项，ActorA 需要有某种方法来确定来自 ActorB 的信息适用于哪个项目。

• ActorA 需要处理它还不知道 ActorB 的地址的情况。

• ActorA 可能应该使用某种超时来避免将工作永远保留在其内部列表中（如果 ActorB 以某种方式从不响应）。

• 如果 ActorA 退出或死亡，它应该在退出之前对仍在数据列表中的项目做一些适当的处理。

下面是第二种实现风格的对应简单示例：

class ActorA(Actor):

    def receiveMessage(self, msg, sender):

        if isinstance(msg, ActorAddress):
            self.actorB = msg

        elif isinstance(msg, WorkRequest):
            x = got_some_data(msg)
            self.send(self.actorB, NeedInfo(x))

        elif isinstance(msg, Info):
            x = msg.orig_request.data
            process_data(x, msg)

class ActorB(Actor):

    def receiveMessage(self, msg, sender):

        if isinstance(msg, NeedInfo):
            i = getinfo(msg)
            i.orig_request = msg
            self.send(sender, i)

在第二个示例中，创建 NeedInfo 的调用将数据存储在.dataNeedInfo 对象的字段中，ActorB 传回的 Info 附加了原始的 NeedInfo 消息。这种风格的注意事项是：

• 无需将原始 WorkRequest 消息与相应的 Info 独立关联，因为它们是相互关联的。

• ActorA 更依赖于 ActorB 的实现，以期望 ActorB 将原始消息附加到其响应中，以允许 ActorA 恢复此上下文。

• ActorA 仍然需要处理它还不知道 ActorB 的地址的情况。

• 如果 ActorA 退出或死亡，则它没有此未完成工作的记录以在清理之前采取任何行动（尽管 Dead Letter 处理程序可以执行此角色）。

上面的示例相当简单，其他 Actor 模型库实现会有一些变化，但无论库/语言如何，这些通用技术都应该广泛应用。这两种实现风格都遵循以下通用 Actor 指南：

1. 收到消息后，做可能的工作

2. 根据需要更新内部状态以处理下一条消息

3. 退出消息处理程序

虽然可以编写执行阻塞操作的 Actor，但该操作会干扰 Actor 的响应能力和处理其他消息的能力（正如您正确指出的），因此尽可能使用消息驱动的延续而不是阻塞调用。