它在文档中说 akka 具有“最多一次交付”，并且不能保证消息到达目的地。
这种行为的原因是什么？未传递的消息会发生什么？他们被认为是迷路了吗？
编辑：我忘记了最重要的部分。有没有可以参考的损失率？ 你知道我对消息传递保证有多么悲观吗（比如有 % 的失败率吗？）.. 仅仅因为我有一个演员集群，他们将在同一个网络服务器上运行，而我没有'不知道我是否应该考虑消息失败是 5 分之一，还是 100 分之一。
【问题讨论】：
标签： java akka distributed-system
因此，Akka 实际上提供了“最多一次交付”和保证交付又称为“至少一次交付”的两种选项。请参阅 cmets 中的the link user1234 posted，了解“至少一次”与“最多一次”的概念。
所以 Akka 可以做任何一种选择。为什么“最多一次”是默认值？
您的问题的简短回答是，切换到有保证的交付至少有五项非常重要的成本：
分布式系统中的保证交付需要持久性（否则在节点故障的情况下您无法保证交付）。然而，这会带来巨大的性能开销。
分布式系统中的保证交付引入了重复交付的机会。 （如果你不能确认交付，基本上你唯一能做的就是重试，引入潜在的重复）。对于某些应用程序，这是有问题的。 （您可以通过重复数据删除来解决这个问题，但这会带来额外的开销，并且通常在应用程序代码中更容易做到。）因此术语“至少一次”。
保证传递也会影响消息顺序。例如您可以在尝试下一个确认之前等待每个确认（这将非常缓慢），或者您可以无序重试。对于许多应用程序来说，这可能是有问题的。
保证交付只是有更多的开销。这包括必要的簿记、基本上将消息保存更长时间的内存，以及网络上的确认聊天。
如上所述，保证交付还需要持久性。但这不仅增加了已经提到的开销，而且还增加了复杂性。特别是因为如果您想很好地处理故障节点和/或扩展/收缩集群，这通常意味着集中存储。
所以，Akka 为您提供了选择。但它也提醒您（在该文档中），对于大多数应用程序来说，通过应用程序代码处理消息传递失败比依靠有保证的传递要容易得多。 （无论是出于性能原因，还是因为保证交付会引入其自身的问题，例如重复消息和乱序消息。）
编辑： 作为对“最多一次”消息传递有多可靠的后续行动的回应，很难给出准确的答案。要理解的关键是，消息传递协议并非天生就是不可靠的。如果您的硬件是 100% 可靠，您的网络是 100% 可靠，您的软件是 100% 可靠，那么您的消息将在 100% 的时间内传递。但是，如果您的网络出现故障，那么您将丢失 100% 的消息。如果您的目标服务器由于 NPE 而崩溃，您将丢失 100% 的消息。
在正常情况下，所有消息都会到达。唯一的问题是您经历异常情况的频率。
【讨论】：