问题标签 [error-kernel]

我有一个非常简单的示例，其中我有一个 Actor ( SimpleActor)，它通过向自身发送消息来执行周期性任务。消息在actor的构造函数中调度。在正常情况下（即没有故障）一切正常。

但是如果 Actor 必须处理故障怎么办。我还有另一个演员 ( SimpleActorWithFault)。这个演员可能有缺点。在这种情况下，我自己通过抛出异常来生成一个。当发生故障（即SimpleActorWithFault引发异常）时，它会自动重新启动。然而，这个重新启动会弄乱 Actor 内部的调度程序，它不再作为例外工作。如果故障发生得足够快，它会产生更多意想不到的行为。

我的问题是在这种情况下处理故障的首选方法是什么？我知道我可以使用Try块来处理异常。但是，如果我正在扩展另一个无法在超类中放置 Try 的演员，或者当我是演员的例外错误时，该怎么办。

我正在尝试遵循最佳实践并在 Akka 中应用错误内核模式。根据这里的报价：

如果一个actor携带了非常重要的数据（即如果可以避免，它的状态不会丢失），这个actor应该将任何可能危险的子任务分配给它所监督的子任务，并适当地处理这些子任务的失败。根据请求的性质，最好为每个请求创建一个新的子请求，这样可以简化收集回复的状态管理。这被称为 Erlang 的“错误内核模式”。

...创建孩子并将容易出错的工作委托给他们是一个好主意，将重要状态集中在父母/主管演员中。

在这种情况下，如果具有重要状态的参与者由于某种原因重新启动，我是否需要处理来自它的陈旧子项（在重新启动之前创建）的消息？

让我们用例子来说明这一点。

让我们假设我有 3 个演员：（A是 的父母/主管B）、B（是 的父母/主管C，包含重要状态）和C。

A的监督策略被配置为在异常时重新启动它的孩子。

C在B的构造函数中创建。

然后让我们假设消息bc是从表单发送B到的C。C开始处理它（让我们想象它在那里运行长时间运行的计算），一旦完成将回复Bwith cb。

现在，让我们假设before cb被发送到并由B A将消息发送ab到处理B。此消息导致B抛出异常，并且由于A的​​监督策略决定B将重新启动。

作为 的子级B C将在B' 重新启动期间停止（C'将在B' 的构造函数中创建新的）。

在重新启动之前发送的重新启动B接收是否会重新启动？cbCB

如果是， ( ) 的子项是否会sender被cb视为Crestarted 的子项B？演员 ref 的C和C'是否相等（假设C和C's 的名字相等）？

我正在使用 Akka，我想为 User Guardian 演员定义我自己的监督策略。我定义了两种类型的actor，称为​​TaskActor 和MessageActor。它们被实例化为顶级演员。我希望用户监护人应用以下监督策略：当他们抛出异常时停止 TaskActor 并恢复 MessageActor（我不介意抛出什么特定类型的异常）。我该怎么做？

参与者如何在复杂的后端服务中使用，这些服务包括接收初始请求、进行一些处理、然后向其他服务发送一些请求/待办事项、等待其中一些服务的响应，并决定如何继续基于响应，等等，直到我们计算出最终结果？

尝试使用参与者来实现此类服务提出了一个问题——该工作流的哪些部分应该由参与者实现，哪些部分不应该？

Actor 实例在他们尝试完成的任务完成之前不会释放他们正在使用的线程（除非我们将它委托给 Future），所以在我看来，它就像将整个工作流程编写为越来越小的 Actor 的层次结构， N 层子节点，一方面是基于 Actor 概念的理想设计，但另一方面它会保持 N-1 个线程（每个初始请求） - 不断锁定，只在底部等待一个层次结构中的演员来完成。具体来说，层次结构中最顶层的参与者大部分时间都是空闲的。

这种分层设计也匹配错误内核模式。

但这听起来对并发性非常不利。

即使你试图保持这种演员的层次结构，但在未来包装对每个演员的调用（通过询问子演员，而不是告诉），所以锁定会更短（尽管它仍然存在） - 仍然有效有这么多的 Futures 使得不可能与有状态的参与者合作，或者无法以自己不同步的方式修改系统状态的参与者（即不简单地修改数据库，至少对于简单的请求来说，这是通过数据库自动完成的事务 - 而是修改应用程序中的一些全局变量）。

那么演员应该只在工作流的较低级别使用吗？

或者应该以更连续的方式重写主要是分层的（并且大多数是）的工作流，因此它不需要这么多级别的子角色（但这将非常困难和不自然，并且似乎也提供了实现框架对设计影响很大）。

这意味着您认识到参与者是非常有限的，并且容错应该主要由传统的异常处理来处理，并且无论如何，拥有容错应用程序的愿望不应该对设计产生太大影响应用。既然如此，何必找演员呢？使用一个需要阅读每个参与者的实现以理解复杂的意大利面条状消息结的工作流程的框架，比使用基于层次结构的框架要容易得多查看方法签名，而不必查看它们的实现。

如果只有一小部分应用程序由参与者实现，参与者的许多好处，例如易于扩展，似乎不太相关或不实用。