在akka.net中使用kinesis进行消息传递是个好主意

Question

我们目前正在Akka.NET之上建立一个带有DDD原则的演员系统。

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

• 默认情况下，在演员
之间交付最多一次
• 演员邮箱的弹性
• FSMActors存储收到的邮件，这些邮件无法立即处理 - 弹性？
• 发布/订阅模式（和弹性）

如果某些消息丢失，我们不确定该怎么办，因此我们无法转到下一个状态来完成请求，这涉及多个参与者。

我的想法是使用像kinesis这样的事件流系统来传递消息。然后我们到处都有弹性，只需知道我们处理过的流中的哪个事件。 我错过了别的什么吗？你认为这是一个观念吗？这是否违反了一些最佳做法？

Answer 1

对于Akka.NET（实际上所有流行的分布式演员模型实现），最多一次交付是一个慎重的选择。在过去，来自JVM的原始Akka在持久队列上实现了邮箱实现，但是这个想法在几年前因为实验失败而被删除。

• Akka.NET主要围绕消息传递。对于每个用户请求，可能会在actor之间传递数十（或数百）条消息以便处理它。使用内存中的消息传递，这是快速而简单的（Akka.NET可以在单个机器内传递数百万msgs /秒）。
• 通常您在可靠处理方面的想法是不可靠的，持久的邮箱很重要。线索是可靠地处理消息 - 您可以轻松地从队列或日志中取消消息，并且机器将在您完成处理之前中断。
• 至少一次处理会强制您能够识别重复项（除了重新传递对每个演员来说都不符合成本效益）或者设计所有处理逻辑以幂等方式工作。

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

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