因此，Akka实际上提供了“最多一次交付”和保证交付（又名“至少一次交付”）两种选择。请参见评论中的the link user1234 posted，以了解“至少一次”与“最多一次”的概念。
所以Akka可以选择任何一种，为什么默认值是“最多一次”？
对你的问题的简短回答是，转向有保证的交付至少有五个非常显著的成本：

• 在分布式系统中保证交付需要持久性（否则在节点故障的情况下您无法保证交付），但是这会引入巨大的性能开销。
• 分布式系统中的有保证的传递引入了重复传递的可能性。（如果您不能确认传递，基本上您唯一能做的事情就是重试，从而引入潜在的重复）。对于某些应用程序来说，这是有问题的。（您可以通过重复数据删除来解决这个问题，但是这引入了额外的开销，并且通常在应用程序代码中更容易做到。）因此术语“至少一次”。
• 有保证的传递也会影响消息的顺序。例如，你可以等待每一个确认，然后再尝试下一个（这会非常慢），或者你可以无序地传递重试。这对许多应用程序来说都是有问题的。
• 有保证的传递只是有更多的开销，这包括必要的簿记，基本上保持消息更长时间的内存，以及确认的网络喋喋不休。
• 如上所述，有保证的交付还需要持久性。但这不仅增加了开销，而且增加了复杂性。特别是如果你想很好地处理故障节点和/或扩展/收缩集群，这通常意味着集中存储。

因此，Akka给了您选择的机会，但它也提醒您（在该文档中），对于大多数应用程序来说，通过应用程序代码处理消息传递失败要比依赖保证传递容易得多（这既是出于性能原因，也是因为保证传递本身也会带来一些问题，如重复消息和乱序消息）。
编辑：为了回应“最多一次”消息传递的可靠性，最好从弹性而不是“可靠性”的Angular 来考虑。换句话说，在正常情况下，“最多一次”和“至少一次”都会传递一条消息。
“最多一次”和“至少一次”的区别在于它们处理问题的方式。例如，假设一个示例应用程序将一百万条消息从节点A上的参与者A发送到节点B上的参与者B。在正常情况下，“最多一次”和“至少一次”都将具有100%的成功率。但是如果我在测试运行中间关闭节点B，“最多一次”应用程序将开始出现网络超时错误，一些消息将失败。然而，“至少一次”版本将保存所有消息到持久性一旦发送。我实际上可以关闭节点A和节点B，等待一个月，重新打开它们，系统将恢复，所有消息将已送达。
要理解的关键是，消息传递协议并不是天生就不可靠：不存在“通常有多少消息将失败”，因为消息在通常情况下即使在“最多一次”中也不会失败。如果您的硬件是100%可靠的并且您的网络是100%可靠的并且您的软件是100%可靠的，则无论使用哪种方法，您的消息都将100%送达。但如果您的网络出现故障，则使用“最多一次”，“至少一次”将丢失0%。如果您的目标服务器由于NPE而崩溃，“最多一次”将丢失100%的邮件，“至少一次”将丢失0%的邮件。
在正常情况下，所有的信息都会到达，唯一的问题是你经历异常情况的频率。