是否有一个标准模式来处理Akka.NET中的参与者中的异常？
我看到了一些模式来创建主管，但似乎SupervisorStrategy是处理演员无法解决的事情的方法。
我有一个接收大量数据的actor，需要将它存储在外部服务器中。外部数据库可能无法访问。如果是，则服务器可能正在重新启动或网络可能已关闭。我不需要重新启动演员或任何东西，我只想通知发件人一些有关正在发生的事情的信息，这样他就可以将消息保留在磁盘上并重新安排以供日后使用。
发件人不是此actor连接到数据库的父级。我应该创建一个主管来处理这个问题吗？或者我应该将我的接收处理程序封装在try / catch块中，并使用Tell通过自定义响应通知发件人a，就像它是正常的消息一样？
我知道有一个Failure课程，但我不确定我是否打算在这种情况下使用它。
答案 0 :(得分：19)
是的。 首先，总是将危险的工作委托给儿童演员，给他们所有的刀，火焰喷射器等。如果他们崩溃和燃烧，你的状态仍然完好，你可以产生新的孩子。
所以对于无法访问的数据库示例;
启动数据库通信演员。
然后你可以让这个actor有两个状态，DB up和DB down，这可以建模为FSM或使用Become / Unbecome。
因此，当消息到达并请求数据库查询时，如果事情爆发，则数据库通信器参与者将其自身置于DB-Down状态。
如果在DB-Down状态下收到任何查询，您可以立即回复Failure事件。
那么我们如何再次从DB-Down转到DB-Up？
DB-Communicator actor可以使用ScheduleOnce自行ping它，例如传递给自己一个＆＃34; CheckDBStatus＆＃34;消息每x秒。
收到CheckDBStatus消息后，检查DB是否再次启动，如果是，则恢复为DB-Up状态。
这样，在高负载无法响应的情况下，您不会充斥数据库，在这种情况下添加更多负载只会使事情变得更糟。 所以这种断路器可以防止这种情况发生。
简而言之：
在DB-Up状态：
如果收到DBQuery消息，请尝试运行查询，然后发回响应。 如果事情爆发，直接进入DB-Down状态并以失败事件作出回应。
在DB-Down状态下：
如果收到DBQuery消息，则直接用Failure事件进行响应，无需触摸数据库。
每隔x秒ping一次以查看DB是否已启动，并在可能的情况下恢复为DB-Up状态。
在这种情况下，你不会使用任何主管来转移状态，正常的try / catch就足以解决这个问题了。
希望这清楚。