众所周知，通常的 Akka Actor 提供最多一次交付语义。另一方面，akka-persistence 还提供至少一次交付语义，后者在实现时需要更多样板和一些差异（即，处理序列号以避免在确认交付后再次接收或发送）。
现在假设您有一些大型企业应用程序处理大量关键事务（例如，一些银行）。此事务在内部建模为组成系统的参与者之间的特定消息流（可能部署在多台机器中）。
因此，如果上述消息流中单个消息的丢失意味着事务失败或被静默丢弃，这种情况是否会强制实现在所有样板中使用至少一次交付？这不会使代码库维护起来很麻烦吗？如何在代码可维护性和整体系统性能的平衡方面有效地处理这种情况？通常如何以安全的方式最小化使用至少一次交付？
非常感谢。
因此，如果上述消息流中单个消息的丢失意味着事务失败或被静默丢弃，这种情况是否会强制实现在所有样板中使用至少一次交付？这不会使代码库维护起来很麻烦吗？如何在代码可维护性和整体系统性能的平衡方面有效地处理这种情况？一般来说，如何以安全的方式最大限度地减少使用至少一次交付？<
你永远不会这样做。在银行系统中，你几乎找不到演员。在银行系统中，您会发现两个或三个级别的实现来确保每笔交易都通过。
对于至少一次方法与最多一次方法基本上是超时和您对消息的思考方式的差异。最多一个是要最大化吞吐量（如果有什么事情发生了，你有超时来启动低级别）。
至少有一次采用不同的路线（取决于底层实现）。在这里，您的目标是缩短响应时间。更有可能将其发送到三台服务器并获得最快的响应。
想想计费服务与搜索服务。在计费服务中，您不太关心响应时间，并希望确保一个人只被计费一次。因此，您希望在请求另一个节点接管并进行计费之前完成一个流程。对于搜索服务，您希望获得快速响应时间。因此，您将搜索请求发送到假设三台服务器，它们并行搜索，然后您获取任何（！）服务器报告的第一个结果。
所以这就是原因。至少一次且最多一次是关于正确性与响应性的。（至少我们是这样学习的）。
[更新]
如果您测量实际性能并发现您的服务器在 25 毫秒内响应 75%，在 75 毫秒内响应 95%，那么您的实现至少一次很可能会等待 25 毫秒，然后将请求发送到另一台服务器，然后再等待 50 毫秒发送第三个请求。因此，您只需添加 30%（只是猜测）即可将预期响应时间缩短至 75% 25ms、95% 至 50ms 和 99% 至 75ms（在理想情况下，每个请求都需要相同的计算时间和不同的计算时间）处理时间取决于架构（或取决于单个节点），而不取决于网络（重负载时间等）。