Actor模型与Akka Actor体系基础总结

前言

最近用业余时间把Flink的RPC基础设施翻了个底朝天，又与之前分析过的Spark RPC机制做了一些对比，越发觉得Actor模型甚为精妙，值得简单记录一下，顺便也可作为日后解析Flink RPC机制的基础入门。

Actor模型

Actor模型由Hewitt、Bishop和Steiger在1973年通过论文《A Universal Modular Actor Formalism for Artificial Intelligence》提出，是一个创新的并发、分布式计算和编程模型。该模型的理念是“万物皆Actor”，即以Actor作为最基本的功能单元，且需要遵循以下几个基本规则。

• 所有的计算都是在Actor中执行的。

• Actor之间只能通过消息进行通信，且消息是不可变的。

• Actor串行处理并响应消息。当一个Actor响应消息时，它可以进行下列操作：

    *     更改状态或行为；
    *     发送有限数量的消息给其他Actor；
    *     创建有限数量的子Actor。
  

Actor一词在此语境下仍然没有确定的中文译名，有人把它翻译为“角色”，大致贴切。

一个符合Actor模型的简单系统如下图所示。Actor本质上是状态、行为、邮箱三要素的集合。

• 状态（State）：Actor内部维护的变量及数据。每个Actor都单独维护自己的状态，与其他Actor隔离。

• 行为（Behavior）：Actor内部定义的一组计算逻辑（如函数），用于处理接收到的消息以及改变状态数据。

• 邮箱（Mailbox）：可以视为与接收方Actor关联的FIFO消息队列。由于Actor串行处理消息，发送方发来的来不及处理的消息会存入邮箱中，接收方再从邮箱逐条获取pending的消息。（当然，一个Actor既可以是发送方也可以是接收方）

可见，Actor模型另辟蹊径解决了并发环境中最棘手的问题，即共享数据的问题。在传统方案中，总需要通过同步机制（锁、信号量、原子性内存操作等）保证共享数据的一致性。但是同步操作的开销都比较大，往往会拖累高并发情况下的性能表现，并且容易引起死锁等其他问题。而Actor模型纯依赖消息传递，消息可以异步、非阻塞地处理，且状态是隔离的，不需要再考虑同步，简单而高效。

当然，Actor的结构也很简洁，单个Actor只需利用单线程执行，所以非常轻量级，1GB的内存可以容纳上百万的Actor实例。

Actor模型有众多成熟的实现，例如Erlang语言的并发机制就是完全基于它来实现的。接下来简要介绍Akka，它是目前最活跃的Actor模型开源项目之一，同时也是Flink RPC的基础。而Spark的旧版本同样使用Akka构建其RPC体系，后来的新版本虽然换用了Netty，但其设计理念仍然可以近似视为简化版的Akka。

Akka Actor体系

Akka官网首页的介绍如下。

高并发、分布式、弹性、消息驱动、基于JVM，这就是Akka的五个关键词，可见是深得Actor模型的精髓。

整个Akka生态分为很多库（也叫模块），如：Actor、Remoting、Cluster、Persistence、Streams、HTTP等。当然，Actor库是Akka核心中的核心，下面也仅简要总结与Actor库相关的基础知识。

Akka Actor是按照树形层次结构来组织的，其关系示意图如下所示。

Akka通过Actor系统（ActorSystem）来管理所有Actor，每个JVM实例内只有一个ActorSystem。当ActorSystem启动时，默认有3个守护（guardian）Actor：

• /：根守护Actor，如同文件系统中的根，最先被创建，最后被销毁；

• /system：系统守护Actor，Akka本身以及基于Akka构建的某些模块会在该路径下创建子Actor；

• /user：用户守护Actor，我们在使用Akka过程中创建的Actor都会位于这个路径下。当调用ActorSystem.actorOf()方法时，会在/user下直接创建；而当调用某Actor的ActorContext.actorOf()方法时，会在该Actor下创建子Actor。

创建或者根据路径查找Actor，返回给用户的都是ActorRef，可以视为Actor实例的不可变、可序列化的句柄（引用），用户通过ActorRef来操作Actor，比如向其发送消息。

下图示出Actor从低级到高级的三层抽象，即Actor、ActorContext和ActorRef，以及它们对应的路径ActorPath。

可见，Actor的实际层级关系维护在上下文实例ActorContext中（ActorContext也包含有向当前Actor发送消息的那个ActorRef），而Actor的路径则维护在ActorRef中。这样就保证了从属于不同ActorSystem的Actor之间可以正常通信。

Actor的层次结构同时也是监督（supervision）机制的基础。当一个Actor失败时，它会通知其父Actor采取相应的动作（如直接恢复、重启、停止或者将失败信息继续向高层传递）。下图示出一个Akka Actor的完整生命周期。

可见，Akka还提供了一些生命周期的触发器方法（称为hook/钩子），用户可以通过重写这些方法来管理Actor的生命周期。特别需要注意的是，如果一个Actor停止，那么它的所有子Actor也会随着停止。

最后有一个问题，整个ActorSystem是如何被驱动的呢？答案是依靠一个中心化组件——Dispatcher（调度器/分发器），负责将Actor和与其关联的邮箱中的消息调度到线程中进行处理。它的原理并不难，形象的图示如下，就不多废话了。