Akka如何用于需要保证交付的解决方案？

我试图理解Akka何时有用，特别是消息传递的非保证性质。从：

如果你真的需要它[保证交付]，通常你不需要

问题是，我能想到的很少情况下，丢失消息是可以接受的。到目前为止，我仅有的例子是：

为只读请求提供服务的应用程序（因为如果消息丢失，客户端可以重试）

状态以幂等方式持续发布（丢弃的消息无关紧要，因为下一条消息将很快传递） 第一个是请求-响应模式，因此不是真正的消息传递，第二个同样与只读状态数据流相关，而不是表示必须对其执行操作的业务事件的消息

此外，他们声称保证交付过于昂贵，并且总是提倡“说”而不是“问”，因此他们的理念似乎与活动采购模型相矛盾（显然，保证交付对于活动采购至关重要，否则就没有确定的世界观）

因此，问题是：如果您有一个订购的情况，保证交付是很重要的（客户行动必须按客户订购，而且显然是有保证的），那么Akka适合吗？为什么其他一些已经有这些语义的系统，比如某种队列（Kafka、activemq等）就没有呢

Akka文件建议，任何额外的担保都应以每个应用程序为基础。我们在我的工作场所也有类似的东西（基于非保证交付语义构建的保证消息传递层），但这意味着所有的应用程序代码都与该层交互，因此在这种情况下，我看不出Akka比任何其他消息传递系统有什么好处

---

我真的很难相信人们不在乎信息是否被传递，尤其是在谈论建立信用卡交易处理系统之类的事情时。

可能的重复（通过谷歌找到的“Akka有什么用”）你链接到的问题和它被接受的答案都没有涉及到保证交货的问题，所以我不确定它是否能与我的相同。链接到这篇文章是一篇很棒的文章，它让事情变得更清楚了。然而，有趣的是，标题是“没有人需要可靠的交付”，而本文最后给出了一个需要可靠交付的示例（无可否认，是在业务层，而不是传输层）。我想我只是厌倦了在业务层反复实现可靠性，因为我系统中的所有应用程序都有相同的要求。只是觉得应该有图书馆对它的支持，但也许没有。