我正在学习本教程：https://doc.akka.io/docs/akka/current/typed/guide/tutorial_3.html并且不太明白什么时候最多一次消息语义更可取，因为尽管我们获得了性能提升，但我们失去了消息的弹性。这种权衡的理由似乎在这里得到了解释：
我们只想在订单实际完全处理并持久化后报告成功。唯一能够报告成功的实体是应用程序本身，因为只有它了解所需的域保证。没有一个通用的框架能够弄清楚特定领域的细节，以及在该领域中什么是成功的。在这个特定的例子中，我们只想在数据库写入成功后发出成功的信号，其中数据库确认订单现在已安全存储。由于这些原因，Akka将保证的责任推卸给了应用程序本身，即您必须使用Akka提供的工具自己实现它们。这使您能够完全控制您想要提供的担保。现在，让我们考虑一下Akka提供的消息排序，以便于对应用程序逻辑进行推理
，但我不太明白这是什么意思。感谢您对理解这一点或本决定的其他考虑因素的任何帮助。
我阅读了这个线程RPC语义，它的确切目的是什么，它似乎提供了一个明确的定义，即使用支付提交作为不想重复的示例的最多一次语义的用例。但从上面引用的段落来看，听起来消息会被发送到以太网上，而不考虑确认消息传递成功或失败的ack。我想知道这两种对最多一次语义的描述是否对各自的域正确，以及如何在另一个stackoverflow线程中获得来自akka的确认。
所有不了解域的东西都可以至少或准确地在一次交付后提供消息已经交付(至少在某些(但不是所有(场景中，保证消息已经处理也是可能和实用的(。如果这是你想要的，这是可以的，但将其与更高级别的东西混为一谈(比如"订单已被持久记录"(几乎肯定会导致基本上不可能调试的错误。
在Akka中，通过让消息包括一个包含ActorRef的字段来发送ack(或其他响应(，并让发送者重新发送未确认的消息(因为ack很有可能被丢弃，所以这些重试会导致至少一次(，至少一次是很容易实现的。ask模式(包含在Akka中(在较高级别上提供了这一点：在Akka-Typed中，这是通过指定适配器函数来实现的，这样当参与者a询问参与者B时，B可以在其协议中发送消息，而a在其协议内获得消息(避免了鸡和蛋的问题(；如果在指定的时间段内没有收到响应，适配器会导致向参与者a发送一条失败消息，参与者a(至少有一次语义会指示a最终重试该消息(。需要记住的关键是，是演员B(或其指定人员：例如，如果B将工作交给一名工人演员，该工人演员可以向a发送确认(决定是否以及何时做出回应，而不是Akka。
如果至少做一次，那么围绕幂等性设计消息传递协议是非常有用的：重试成功的消息不会产生超出ack的副作用。幂等加至少一次被称为"；有效地一次"；而且它比以前更容易实现，重量也更轻。
Akka关于交互模式的文档描述了Akka中的各种消息传递模式，并讨论了优缺点。最近，特别是在使用Akka Cluster和Akka Persistence时，出现了一种相当重量级的可靠传递实现：在最大可靠性模式下(使用Akka Persstence(，因为以这种方式发送的每个消息都被持久化到数据存储(例如，本地磁盘或cassandra，或…(，所以消息发送的延迟会严重增加。