actor->actor 或 service->actor 调用的底层机制是什么?它们的可靠性如何?

What are underling mechanisms of actor->actor or service->actor calls and how reliable they are?

我想了解有关在 Azure Service Fabric 中调用 Actors 的底层机制的更多技术细节,我无法在网上轻松找到这些细节。 Actor 以其单线程作用域而闻名,因此除非其任何方法执行完全完成,否则不允许其他客户端调用它。

更具体地说,我需要知道如果 Actor 在一次客户端调用启动的作业中卡住一段时间会发生什么。其他客户应该等多久才能完成工作?秒、分钟、小时?

关于 actor 机制的详细信息以及文档中有很多 SO 答案,我可以指出一些:

这个并没有完全回答你的问题,但我稍微描述了锁定的工作原理:

Q: Is there any time-out mechanism, and if so is it somehow configurable?

是的,有超时,我这里已经回答了:

配置文档位于here

Q: What happens if node where actor is located crashes, would client receives immediate error, or ActorProxy somehow handles this situation and redirects call to newly created instance of Actor on healthy node?

通常当一个副本出现故障时总有一个副本可用,当 SF 将次要副本提升为主要副本时,新请求将开始移动到新副本。

关于通信,默认情况下,SF Actors 使用 .Net Remoting 以与可靠服务相同的方式进行通信,行为在 here 中有很好的描述,总之,它会重试瞬态故障,如果客户端无法连接到服务(Actor),它将重试直到达到连接超时。

From the docs:

The service proxy handles all failover exceptions for the service partition it is created for. It re-resolves the endpoints if there are failover exceptions (non-transient exceptions) and retries the call with the correct endpoint. The number of retries for failover exceptions is indefinite. If transient exceptions occur, the proxy retries the call.

演员docs,有更多的信息,总结起来有两点要记住:

  • Message delivery is best effort.
  • Actors may receive duplicate messages from the same client.

这意味着,如果在传递消息时出现暂时性故障,即使消息已经传递,它也会重试,从而导致重复消息。