什么时候应该使用 Actor 模型？答案

【问题标题】：When should one use the Actor model?什么时候应该使用 Actor 模型？
【发布时间】：2010-12-21 06:59:17
【问题描述】：

什么时候应该使用Actor Model？

它当然不能保证无死锁的环境。

A 可以等待 B 的消息，而 B 等待 A。

此外，如果参与者必须确保其消息在继续其下一个任务之前已得到处理，则它必须发送消息并等待“您的消息已处理”消息，而不是直接阻塞。

模型的威力是什么？

【问题讨论】：

标签： multithreading concurrency functional-programming actor actor-model

【解决方案1】：

我不是演员专家，但这是我在使用演员模型时的 2 美分： Actor 模型并不适合每个并发应用程序，例如，如果您正在创建一个多线程并在高并发下工作的应用程序，则 Actor 模型并不是为了解决并发问题。当你创建一个事件驱动的应用程序时，actor 真正发挥作用的地方。例如，您有一个应用程序，并且您正在跟踪用户在您的应用程序中实时点击的内容。由于参与者是有状态的，因此您可以使用参与者执行按用户、设备或任何业务需求实时隔离的活动。因此，例如，如果某些用户位于点击shirts 的演员中，您可以向他们发送一些优惠券的通知。演员派上用场的一些应用还有：金融（定价、欺诈检测）、多人游戏。

【讨论】：

【解决方案2】：

Actor 的用法至少在两种情况下是“自然的”：

当您可以将问题分解为一组独立的任务时。
当您可以将问题分解为一组由清晰的工作流链接的任务时（即dataflow programming）。

例如，如果您使用一系列过滤器处理复杂数据，则很容易使用参与者管道，其中每个参与者从上游参与者接收数据并将数据设置给下游参与者。

当然，这个数据流一定不是线性的，如果你的管道中的一个步骤很慢，你可以使用一个演员池来做同样的工作。解决负载平衡问题的另一种方法是使用一种由虚拟Kanban 系统组织的需求驱动方法。

当然，在几乎所有有趣的情况下，你都需要演员之间的同步，但与经典的多线程方法相反，这种同步真的很“具体”。你可以想象一个工厂里的人，想象可能出现的问题（工人没有工作要做，上游操作太快，中间产品需要一个巨大的存储空间等）。以此类推，你可以更容易地找到解决方案。

【讨论】：

补充一点，面向对象编程的优点之一是数据和相关功能的封装。但是，仍然需要通过调用对象的一种方法来“赋予”对象“生命”。我们在那里有一个单独的对象和进程视图。另一方面，参与者本身就是进程。这使得将它们与现实世界联系起来变得很容易。

【解决方案3】：

Actor 是异步和并发的，但不保证消息的顺序或时间限制，即何时可以对消息进行操作。因此，原子事务不能拆分为 Actor。

如果应用程序/任务不涉及可变状态，那么由于 Actor 框架竭尽全力避免竞争条件，Actor 就显得过分了。

【讨论】：

【解决方案4】：

考虑到一些并发问题，你会根据什么来决定是否使用actor？

首先我要定义问题...主要动机是加速嵌套 for 循环还是递归？如果是这样，一个简单的基于任务的方法或并行循环方法可能对您（而不是参与者）很有效。

但是，如果您有一个涉及依赖关系和协调共享状态的更复杂的系统，那么参与者方法可以提供帮助。特别是通过使用参与者和消息传递语义，您通常可以避免使用显式锁来保护共享状态，方法是实际复制该状态（消息）并对其做出反应。

你可以很容易地用经典的同步问题来解决这个问题，比如哲学家进餐和睡觉的理发师问题。但是你也可以使用“actor”来帮助实现更现代的模式，即你的外观可以是一个actor，你的模型视图和控制器也可以是相互通信的actor。

我观察到的另一件事是，大多数开发人员都可以学习参与者语义，并且比锁定的同行“更安全”。这是因为它们提高了抽象级别并允许您专注于协调对该数据的访问，而不是使用锁保护对数据的所有访问。例如，假设您有一个带有数据成员的简单类。如果您选择在该类中放置一个锁以保护对该数据成员的访问，则该类上的任何方法都需要确保它们正在访问该锁下的该数据成员。当其他人（或您）在以后修改该类时，这变得特别成问题，他们必须记住使用该锁。

另一方面，如果该类成为参与者，并且数据成员成为您通过消息与之通信的缓冲区或端口，则您不必记住获取锁，因为语义是内置在缓冲区中的，您将非常明确地知道您是否要根据缓冲区的类型阻止它。

-瑞克

【讨论】：