什么时候在akka / erlang中使用actor不好？

我每天与akka合作7-8个月。当我开始时，我将在应用程序上工作，并注意到actor基本上会在actor系统内部的任何地方用于大多数对象之间的通信。所以我也做同样的事情-为x / y / z旋转另一个演员。

在我看来，这可能太过随意了，在不需要的地方增加了复杂性-但是我找不到关于应该使用参与者与普通同步甚至是期货的异步逻辑的讨论。我的同事提到类似的内容后，我开始思考自己的立场。我最近才意识到有几种情况，我在考虑一个任务，然后避免创建另一个参与者，因为我可以在不可变的实现中安全地实现相同的结果-例如，从数据库或文件中获取配置值的地方，而这些地方很少访问并且会等待结果是实际用例。

尤其是在我看来，在任何情况下，如果您正在使用不可变状态，参与者都会造成复杂性并限制吞吐量-例如，对象中的纯函数可以在没有任何并行级别的情况下并发调用，但是演员一次只能处理一条消息。另一个考虑因素是，如果您需要等待结果，除非您开始使用期货，否则就将线程停放，但是在不需要担心异步消息传递或扩展的情况下，聘请演员似乎过大。

所以我的问题是-使用演员的时间不好吗？我很好奇erlang看起来如何并且真的希望别人的见识。或者，如果有一些有关演员使用的原则。

这是我感兴趣的问题，我一直在进行一些研究。对于其他观点，请参阅Noel Walsh的博客文章或有关Stack Overflow的问题。我想提出一些意见：

• 我认为Akka可以处理消息，因此可以鼓励“推送思维方式”。通常，为了并发，我会说这不是您想要的。拉动要安全得多。例如，分布式系统的一种常见模式是让一组工人在队列中处理信息。显然，这在Akka中是可能的，但不一定是人们尝试的第一种方法。Akka还提供持久邮箱，但这又取决于您的使用方式-单个共享队列比每个工作人员队列灵活得多，可以平衡/重新分配工作。
• 很容易陷入用演员替换班级的想法。实际上，有些人甚至通过说演员只能做一件事来主张这一点。逻辑上得出结论，这会像Jason所描述的那样增加代码的复杂性，因为如果每个类都是一个演员，那将带来很多额外的消息以及接收/发送块。由于失去了接口的形式性，这也使理解和测试代码变得更加困难-而且我不相信注释是解决此问题的方法。同样，尽管Akka具有传奇般的效率，但我怀疑演员的增长并不是明智的性能选择-当我们使用Java线程时，我们知道它们是宝贵的，因此可以保存它们。
• 它与上一点有关，但是另一个烦人的地方是Noel和Pino强调的类型信息的丢失，对于我们许多人来说，这就是为什么我们使用Scala而不是其他语言（例如Python）的原因。有一些解决方法，但是它们不是标准的，不推荐的或实验性的。
• 最后，即使您有“让它崩溃”的心态，并发也很难。替代编程模型可以提供帮助，但是它们并不能使问题消失（可以解决问题），这就是为什么正式考虑它们的原因。这也是Joe Average开发人员可以使用现成的工具（例如RabbitMQ，Storm，Hadoop，Spark，Kafka或NoSQL数据库）的原因。Akka确实有一些预构建的工具和组件，这很酷，但是感觉还很低，因此，更多现成的分布式系统通用元素可以帮助开发人员并确保系统正确构建。

像杰森一样，我很想在这里听到其他人的见识。我该如何解决上述一些问题并更好地使用Akka？

值得考虑参与者模型的用途：参与者模型是

1. 并发模型
2. 避免同时访问可变状态
3. 使用异步通信机制提供并发。

这很有价值，因为从多个线程使用共享状态非常困难，尤其是当共享状态的不同组件之间存在必须保持同步的关系时。但是，如果您具有以下域组件：

• 您不允许并发，或者
• 您不允许可变状态（例如在函数编程中），或者
• 您必须依靠某种同步通信机制，

那么参与者模型将不会提供太多（如果有）收益。

希望能有所帮助。

您的直觉是正确的，恕我直言。到处都使用演员就像拥有众所周知的锤子，只看到钉子一样。

Erlang最佳实践是对同时发生的所有活动使用流程/参与者。也就是说，就像现实生活中一样。有时很难找到正确的粒度，但是大多数情况下，您只是通过查看建模域并使用一些常识就知道了。恐怕我没有比这更好的方法了，但是我希望它会有所帮助。

为了输入/输出消息传递：

我最近遇到了一个基于akka的应用程序，其中actor模型实际上引起了并发问题，一个简单的模型在负载下就足够了。

问题在于传入的消息在不同的“通道”（通过不同的actor路径）中移动，但是代码假定消息将以到达的最终顺序到达它们的最终目的地。只要数据以足够大的间隔到达，就可以正常工作，因为只有一条冲突的消息会争夺目的地。当间隔减小时，它们开始混乱，并引起奇怪的行为。

使用较少的actor可以正确解决该问题，但这是过度使用它们时容易犯的错误。

我认为Actor有两个用例。共享资源（例如端口等）和大状态。到目前为止，讨论已经很好地涵盖了第一个，但是大状态也是一个正当的理由。

每个过程调用传递的大型结构可能会占用大量堆栈。可以将该状态放入一个单独的进程中，将结构替换为进程ID，然后根据需要查询该进程。

可以将诸如失忆症之类的数据库视为在查询过程外部存储状态。