什么时候在企业应用程序中至少使用一次交付语义？

Question

众所周知，通常的阿克卡演员最多只提供一次传递语义。另一方面，akka-persistence还提供了至少一次的传递语义，后者在实现时需要更多的样板和一些差异(即，处理序列号以避免在确认传递后再次接收或发送)。

现在假设您有一些大型企业应用程序处理大量关键事务(例如，一些银行)。该事务在内部建模为组成系统的参与者之间的特定消息流(可能部署在多台计算机中)。

因此，如果上述消息流中单个消息的丢失意味着事务失败或被默默丢弃，这种情况是否会迫使实现至少使用一次传递，并且所有模板都在各处？这难道不会使代码库的维护变得有些麻烦吗？如何在代码可维护性和总体系统性能的平衡方面有效地处理这种情况？如何在一般情况下以安全的方式尽量减少至少一次交货的使用？

非常感谢。

Answer 1

因此，如果上述消息流中单个消息的丢失意味着事务失败或被默默丢弃，这种情况是否会迫使实现至少使用一次传递，并且所有模板都在各处？这难道不会使代码库的维护变得有些麻烦吗？如何在代码可维护性和总体系统性能的平衡方面有效地处理这种情况？如何在安全的way?<中尽量减少至少一次交付的使用

你永远不会这么做的。在银行系统里，你很难找到演员。在银行系统中，您将发现两到三个级别的实现，以确保每个事务都通过。

对于至少一次方法和最多一次方法来说，方法基本上是超时和您对消息的思考方式的不同。最多有一个是要最大限度地提高吞吐量(如果有问题发生，那么就需要在较低的级别上启动超时)。

至少有一次采用不同的路径(取决于底层实现)。在这里，您的目标是缩短响应时间。它更有可能发送到三个服务器，prio，并采取最快的反应。

考虑一下计费服务与搜索服务。在计费服务中，您不太关心响应时间，并且希望确保一个人只收到一次账单。因此，在要求另一个节点接管并进行计费之前，您需要完成一个进程。对于搜索服务，您希望有快速响应时间。因此，您将搜索请求发送给三个服务器，它们并行地进行搜索，您将获得由任意(!)报告的第一个结果。服务器。

这就是原因所在。至少一次，最多一次是关于正确性与反应。(至少我们是这么学的)。

更新

如果您测量实际性能，并且发现您的服务器在25 ms内响应75%，在75 ms内响应95%，那么您的实现至少一次很可能等待25 ms，然后将请求发送到另一台服务器，然后等待50 ms发送第三次请求。因此，您只需添加30% (只是猜测)即可将预期响应时间缩短到75% 25 of、95%至50 of和99%至75 of(在理想的世界中，每个请求都需要相同的计算时间，处理时间的差异取决于体系结构(或取决于单个节点)，而不是取决于网络(重负载时间等))。