Akka官方文档2.5.17（二）—什么是Actor？

目录

 

什么是Actor？

Actor引用

状态

行为

邮箱

子Actors

监督策略

当Actor终止

---

什么是Actor？

前面关于ActorSystem的一节，解释了Actors如何形成层级结构，并且是构建应用的最小单元。本小节单独看一个Actor，解释在实现这样一个Actor时的概念。相关细节的更深入参考，可参见Actors。

一个Actor是状态、行为、邮箱、子Actors以及监督策略的容器。所有这一切都被封装在Actor引用中。一个值得注意的方面是Actors都有一个明确的生命周期，它们在没有任何引用时也不会自动销毁；当创建了一个Actor，那么就是你的责任确保它最终会终止——同时也给了你当Actor终止时资源如何释放的控制权限。

Actor引用

如下所述，为了从Actor模型中受益，一个Actor对象不应该暴露给外部对象。因此，通过Actor引用给外部对象使用，Actor引用可以任意且无限制的传递。这种划分为内部和外部对象的方式使得对于所有操作保持透明性成为可能：如重启一个Actor而不需要更新Actor引用，将真正的Actor对象放置在远程机器上，向完全不同的应用程序发送消息。但最最重要的方面是不能查看Actor的内部并从外部获取Actor内部的状态，除非Actor自身暴露这些信息。

状态

Actor对象通常包含了一些反映Actor可能处于的状态的变量。这可能是一个显式状态机（比如使用FSM模块），或者一个计数器，一组listener集合，待处理请求等等。这些数据是Actor存在的意义，所以必须保护它们免受因其他Actor出错而带来的影响。好消息是，Akka Actor从概念上来说，每个都拥有自己的轻量级线程，完全屏蔽了系统的其他部分。这意味着不需要使用锁来进行同步访问，而可以轻松的编写Actor代码且不用担心并发性。

在幕后，Akka会在一组线程上调用一组Actors，通常许多Actors共享一个线程，并且一个Actor的后续调用最终可能会在不同的线程上处理，Akka保证这种实现细节不会影响处理Actor状态的单线程有效性。

因为内部状态对于Actor的状态至关重要，具有不一致的状态是致命的。因此，当Actor失败且被它的监督者重启时，将会从头构建它的状态，就像第一次创建Actor一样。这是为了实现系统的自我修复能力。

可选的，通过持久化接收到的消息并在重启后重新执行，可以自动将Actor恢复到重启前的状态。（请参阅持久化）

行为

每次处理消息时，都会根据当前的Actor行为进行匹配。行为是指定义了在某时间点对消息作出反应的函数，例如：如果客户端已经授权则转发请求，否则拒绝请求。这个行为可能会随时间而发生改变，例如：不同的客户端随着时间的推移获得授权，或者Actor会“宕机”然后又重新提供服务。这些改变通过将它们封装在状态变量中，然后通过行为的逻辑去读取，或者函数本身在运行时自动切换来实现，查阅become和unbecome操作。然而，在Actor构造期间定义的初始行为是特殊的，因为每次重启Actor都会将其行为重置为初始行为。

邮箱

一个Actor的目的是为了处理消息，这些消息从其他Actors（或者Actor系统外部）发送给当前Actor。Actor邮箱是连接发送者和接受者的部分：每个Actor有且只有一个邮箱，所有发送者的消息都将会入队。入队按发送操作的时间顺序进行，这意味着由于随机的分配线程对Actor进行处理，不同Actors发送的消息没有明确的顺序。另一方面，从同一个Actor向同一目标发送的多个消息将以相同的顺序入队。

有多种不同的邮箱实现策略，默认情况下是FIFO队列：消息的处理顺序与它们入队的顺序相同。这通常是一个好的默认方式，但是应用程序可能需要优先处理部分消息。在这种情况下，一个优先级邮箱的入队操作不会总是在队列末，而是根据消息的优先级排在指定位置，甚至可能在队列前面。当用这样一个队列时，处理消息的顺序通常由队列自己的算法定义，通常情况下不是FIFO。

Akka和其他一个Actor模型的不同之处在于，当前行为必须处理下一个出列的消息，没有扫描邮箱并找到下一个匹配的消息功能。无法处理消息通常被视为失败，除非显式的覆盖该行为。

子Actors

每一个Actor都可能是一个监督者：如果它创建子Actor来委派子任务，它将会自动监督它们。子Actors会保存在该Actor上下文的列表中，并且该Actor可以访问它们。通过创建 context.actorOf(...)或者停止 context.stop(...)来完成对列表的修改。实际的创建和停止操作会以异步的方式在幕后执行，所以不会阻塞它们的监督者。

监督策略

Actor的最后一部分是子Actor的错误处理策略。通过对每个错误运用监督和监控中的某个策略，Akka可以对其进行透明处理。因为策略是Actor系统结构的基础，所以一旦创建，就无法在运行时更改。

考虑到每个Actor有且仅有一种策略，这意味着如果Actor的子节点需要不同的策略进行处理时，那么这些子节点应该按照不同的策略进行分组，并与不同的中间监督者进行匹配。根据将任务划分为子任务的形式，再次优先考虑Actor系统的层次结构。

当Actor终止

一旦一个Actor终止时，比如错误没有被捕捉并重启，自行停掉自己，被监督者停掉等等。这时会释放它的资源，将所有剩余的未处理消息转移到系统的“dead letter邮箱”，然后当作DeadLetters发送到EventStream。然后，Actor引用中的邮箱会被替换为系统邮箱，消息直接重定向为DeadLetters发送到EventStream。这是在尽力而为的基础上完成的，所以不要依赖这种机制去构建“guaranteed deliver”。

不仅仅是默默地转储消息的原因是为了测试：我们在转发dead letters的事件总线上注册了TestEventListener，它会在收到每封dead letter后记录警告 - 这对更快地辨别失败的测试很有帮助 。 可以想到，该特征也可用于其他目的。