C# 如何处理参与者内部的异常？

Akka.NET中是否有标准模式来处理参与者内部的异常

我看到了一些创建监管者的模式，但似乎

监管者策略

是一种处理演员无法解决的问题的方法

我有一个actor，它接收大量数据并需要将其存储在外部服务器中。外部数据库可能无法访问。如果是，服务器可能正在重新启动，或者网络可能已关闭。我不需要重新启动actor或其他任何东西，我只想通知发送者一些关于正在发生的事情的信息，这样他就可以将消息保存在磁盘上并重新安排以后的时间

发件人不是连接到数据库的此参与者的父级。我是否应该创建一个主管来处理这个问题？或者我应该将我的接收处理程序封装在try/catch块中，只使用

Tell

以自定义响应通知发送者，就像它是普通消息一样

我知道有一个

失败

类，但我不确定在这种情况下是否应该使用它。

是的。 首先，总是把危险的工作交给儿童演员，把你所有的刀子、火焰喷射器等等都交给他们。如果它们崩溃并烧毁，你的状态仍然完好无损，你可以生下新的孩子

所以对于不可访问的数据库示例； 启动DB通信演员。 然后，您可以让这个参与者有两种状态，DB up和DB down，可以将其建模为FSM或使用

been

/

Unbecome

因此，当消息到达并请求DB查询时，如果出现问题，DB communicator actor会将其自身置于DB Down状态。 如果在DB Down状态下接收到任何查询，您可以立即响应

故障

事件

那么我们如何从DB下降到DB上升呢？ DB Communicator actor可以使用

ScheduleOnce

自行ping，例如每x秒向其发送一条“CheckDBStatus”消息。 当收到CheckDBStatus消息时，检查DB是否再次启动，如果是，则恢复到DB up状态

这样，在由于高负载而导致数据库无法响应的情况下，您就不会使数据库泛滥，在这种情况下增加更多负载只会使情况变得更糟。 所以这种断路器可以防止这种情况发生

简言之：

在DB Up状态下：

如果收到DBQuery消息，请尝试运行该查询并发回响应。 如果发生故障，直接进入DB Down状态，并以故障事件进行响应

在DB Down状态下： 如果收到DBQuery消息，则直接响应

故障

事件，而不接触数据库。 每x秒Ping一次，查看DB是否启动，如果可能，恢复到DB启动状态

在这种情况下，您不会使用任何主管来传输状态，正常的try/catch就足以处理这种情况

---

希望这能把事情弄清楚。

是的，确实如此。只有一件事：

失败

事件只是我创建并发送的自定义消息，还是有什么特别的东西？这只是一个常见事件，有一个内置的“失败”事件用于一般目的，我是对的，这个DB通信参与者应该是顶级参与者？@JoelMueller不是你问题的答案，但是我设法挖掘到了一些信息：

Akka.Actor.Failure

是，它的用法存在，但类仍然存在

Akka.Actor.Status.Failure

是：“[…]用于内部确认协议，但如果需要，还作为实用程序类公开用于用户特定的确认。”@JoelMueller您找到过这个问题的答案吗？我遇到了同样的失败，抛出异常并丢失了我的实际异常。Roger的回答是正确的，但我想链接到一个详细的解释，说明层次监督和错误内核模式在Akka.NET中是如何工作的：