Akka：-为什么消息不能保证(发送后)到达？消息的失败率是多少？

Question

它在文档中说akka“最多一次交付”，并且不能保证消息到达目的地。

出现这种行为的原因是什么？未送达的消息会发生什么情况？他们被认为是迷路了吗？

编辑:我忘记了最重要的部分。有没有我可以参考的损失率？你知道我对消息传递保证有多悲观吗(比如有%的失败率吗？)..只是因为我有一群参与者，他们将在同一个web服务器上运行，我不知道我是否应该考虑消息失败是1/ 5还是1/ 100。

Answer 1

因此，Akka实际上提供了“至多一次交付”和“至少一次交付”的保证交付两种选择。有关“至少一次”与“至多一次”概念的详细介绍，请参阅评论中的the link user1234 posted。

所以Akka可以做任何一种选择。为什么“最多一次”是默认的？

对您的问题的简短回答是，切换到保证交付至少有五个非常重要的成本：

分布式系统中的

• 保证交付需要持久性(否则在节点发生故障的情况下无法保证交付)。这带来了巨大的性能开销，分布式系统中的however.
• Guaranteed交付带来了重复交付的机会。(如果你不能确认交付，从根本上说，你唯一能做的就是重试，引入潜在的重复项)。对于某些应用程序来说，这是有问题的。(您可以使用重复数据删除来解决此问题，但这会带来额外的开销，并且通常更容易在应用程序代码中完成。)因此，术语“至少once".
• Guaranteed传递也会影响消息顺序”。例如，您可以在尝试下一次确认之前等待每次确认(这将非常慢)，或者您可以不按顺序发送重试。对于许多应用程序来说，这可以是problematic.
• Guaranteed交付，但开销要大得多。如上所述，这既包括必要的记账，也包括基本保持消息更长时间的内存，以及acknowledgements.
• Guaranteed交付的网络聊天也需要持久性。但如前所述，这不仅增加了开销，而且还增加了复杂性。特别是因为如果您想要很好地处理故障节点和/或扩展/收缩群集，这通常意味着集中存储。

所以，Akka给了你选择。但它也提醒您(在该文档中)，对于大多数应用程序来说，通过应用程序代码处理消息传递失败要比依赖保证传递容易得多。(这既是出于性能原因，也是因为保证交付引入了自身的问题，如重复消息和乱序消息。)

编辑:对于“最多一次”消息传递的可靠性，很难给出一个确切的答案。要理解的关键是，消息传递协议并不是天生就不可靠。如果您的硬件是100%可靠的，您的网络是100%可靠的，您的软件是100%可靠的，那么您的消息将在100%的时间内送达。但是如果你的网络中断了，那么你将会丢失100%的消息。如果您的目标服务器由于NPE而崩溃，您将丢失100%的消息。

在正常情况下，所有消息都会到达。唯一的问题是你多久会遇到一次不正常的情况。