Actor 模型如何满足现代分布式系统的需求？
如前一主题「为什么现代系统需要新的编程模型」所述，常见的编程实践不能合适地满足现代系统的需求。幸运的是，我们不需要放弃我们所知道的一切。相反，Actor 模型以一种原则性的方式解决了这些缺点，允许系统以更好地匹配我们的构思模型（mental model）的方式运行。Actor 模型抽象允许你从通信的角度来考虑你的代码，这与大型组织中人员之间发生的交换没有什么不同。
使用 Actor 允许我们：
- 在不使用锁的情况下强制封装。
- 利用协同实体对信号作出反应、改变状态、相互发送信号的模型来驱动整个应用程序向前发展。
- 不要担心执行机制与我们的世界观（
world view）不匹配。
消息传递的使用避免了锁和阻塞
Actor 不调用方法，而是互相发送消息。发送消息不会将线程的执行权从发送方传输到目标方。Actor 可以发送一条消息并继续其他操作，而不是阻塞。因此，它可以在相同的时间内完成更多的工作。
对于对象，当一个方法返回时，它释放对其执行线程的控制。在这方面，Actor 的行为非常类似于对象，它们对消息作出反应，并在完成当前消息的处理后执行返回。通过这种方式，Actor 实际上实现了我们设想中对象的执行方式：
传递消息和调用方法之间的一个重要区别是消息没有返回值。通过发送消息，Actor 将工作委托给另一个 Actor。正如我们在「调用栈的假象」中看到的，如果它期望返回值，那么发送 Actor 要么阻塞，要么在同一线程上执行另一个 Actor 的工作。相反，接收 Actor 在回复消息中传递结果。
我们模型中需要的第二个关键改变是恢复封装。Actor 对消息的反应就像对象对调用它们的方法“反应”一样。不同之处在于，不同于多个线程“突出（protruding）”到 Actor 中并对内部状态和不变量造成严重破坏，Actor 的执行动作独立于消息的发送者，并对传入消息依次作出反应，一次一个。当每个 Actor 按顺序处理发送给它的消息时，不同的 Actor 同时工作，以便 Actor 系统可以同时处理硬件所支持的尽可能多的消息。
由于每个 Actor 最多只能同时处理一条消息，因此可以不同步地保留 Actor 的不变量。这是自动发生的，不使用锁：
总之，当 Actor 收到消息时会发生以下情况：
- Actor 将消息添加到队列的末尾。
- 如果 Actor 没有执行计划，则将其标记为准备执行。
- 一个（隐藏的）调度程序实体获取 Actor 并开始执行它。
- Actor 从队列前面选择消息。
- Actor 修改内部状态，向其他 Actor 发送消息。
- Actor 没有预约（
unscheduled）。
为了完成上面的行为，Actors 有：
- 一个邮箱（消息结束的队列）。
- 一个行为（Actor 的状态、内部变量等）。
- 消息（表示信号的数据片段，类似于方法调用及其参数）。
- 一个执行环境（一种机制，它让具有消息的 Actor 对其消息处理代码作出反应并调用它们）。
- 一个地址（稍后将详细介绍）。
消息进入 Actor 邮箱。Actor 的行为描述了 Actor 如何响应消息（如发送更多消息和/或更改状态）。执行环境协调线程池以完全透明地驱动所有这些操作。
这是一个非常简单的模型，它解决了前面列举的问题：
- 通过将执行与信号分离（方法调用转换执行权，消息传递不这样做），可以保留封装。
- 不需要锁。修改 Actor 的内部状态只能通过消息来实现，一次处理一条消息，在试图保持不变时消除竞争。
- 任何地方都没有使用锁，发送者也不会阻塞。数百万个 Actor 可以有效地安排在十几个线程上，从而充分发挥现代 CPU 的潜力。任务委托是 Actor 的天然执行方式。
- Actor 的状态是本地的而不是共享的，更改和数据通过消息传播，消息是映射到现代内存架构的实际工作方式。在许多情况下，这意味着只传输包含消息中数据的缓存线，同时将本地状态和数据缓存在原始核心上。相同的模型可以完全映射到远程通信中，其中状态保存在机器的 RAM 中，更改/数据作为数据包在网络上传播。
Actor 能够优雅地处理错误情况
由于我们不再拥有在相互发送消息的 Actor 之间共享的调用栈，因此我们需要以不同的方式处理错误情况。我们需要考虑两种错误：
- 第一种情况是，由于任务中的错误（通常是一些验证问题，如不存在的用户 ID），目标 Actor 上的委派任务失败。在这种情况下，由目标 Actor 封装的服务是完整的，只有任务本身是错误的。服务 Actor 应该用一条消息回复发送者，并显示错误情况。这里没有什么特别的，错误是域的一部分，因此错误也是普通消息。
- 第二种情况是当服务本身遇到内部故障时。Akka 要求所有 Actor 都被组织成一个树形的结构，即一个创造另一个 Actor 的 Actor 成为新 Actor 的父节点。这与操作系统将流程组织到树中的方式非常相似。就像处理过程一样，当一个 Actor 失败时，它的父 Actor 会得到通知，并且它可以对失败做出反应。另外，如果父 Actor 被停止，那么它的所有子 Actor 也将被递归地停止。这项服务称为监督，是 Akka 的核心概念。
一个监督者（父级节点）可以决定在某些类型的失败时重新启动其子 Actor，或者在其他失败时完全停止它们。子 Actor 永远不会默不作声地死去（除了进入一个无限循环之外），相反，他们要么失败，他们的父级可以对错误作出反应，要么他们被停止（在这种情况下，相关方会被自动通知）。总是有一个负责管理 Actor 的实体：它的父节点。从外部看不到重新启动：协作 Actor 可以在目标 Actor 重新启动时继续发送消息。
现在，让我们简单介绍一下 Akka 提供的功能。
英文原文链接：How the Actor Model Meets the Needs of Modern, Distributed Systems.
