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