在akka.net中使用动态传递消息是个好主意吗？

Question

我们目前正在构建一个基于Akka.NET的DDD原则的参与者系统。

在如何使我们的服务具有弹性方面，我们缺少了几点：

• 在行为者之间默认情况下最多交付一次。
• 行为者邮箱的复原力
• FSMActors正在存储传入的消息，而这些消息无法立即处理--恢复力？
• Pub/Sub模式(和复原力)

如果有些消息丢失了，我们不知道该怎么办，因此我们不能转移到下一个状态来完成一个请求，该请求涉及多个参与者。

我的想法是使用事件流系统，比如动态传递消息。然后我们在任何地方都有弹性，只需要知道我们处理过的流中的哪个事件。我是不是漏了什么东西？你觉得这是goot的主意吗？这是否违反了一些最佳做法？

Answer 1

对于Akka.NET (以及实际上所有流行的分布式参与者模型实现)来说，一次性交付是一个深思熟虑的选择。在过去，来自JVM的原始Akka在持久性队列上有邮箱实现，但是这个想法在几年前作为失败的实验而被放弃了。

• Akka.NET在很大程度上是面向消息传递的。对于每个用户请求，可能有数十条(或数百条)消息在参与者之间传递以处理它。使用内存中的消息传递，这是快速和容易的(Akka.NET可以传递数百万msgs/秒。在单机内)。
• 通常，当涉及到可靠的处理时，您所想到的是不可靠的、持久的邮箱。关键是要可靠地处理一条消息--您可以轻松地从队列或日志中取出消息，机器在完成处理之前就会中断。
• 至少有一次，处理强制您要么能够识别副本(除了重发是不符合成本效益的每一个参与者)，或者设计你所有的处理逻辑以幂等的方式工作。

在某些情况下，有确认就足够了，例如，用户发送请求并期望响应在某个超时内到达。如果答复没有到达，即因为一些消息丢失了，只需将一个失败返回给请求者(并可能要求他/她重试)。

另一种常见的模式是在特定的位置使用队列/日志，即作为参与者系统前面的层。这样，所有的用户请求都首先发送到持久队列，然后由参与者系统逻辑从队列中获取它们。一旦内部参与者完成了请求的处理，他们就可以提交请求并从队列中删除。如果发生了某些故障，则只需重新尝试整个过程(或其中的一部分)。