这可能会导致有偏见和基于意见的答案，如果是这样，我会结束这个问题，但是......
我有一个相当基本的要求，即提高我们的正常运行时间和速度。作为其中的一部分，我正在研究两种主要的竞争方法，传统的 pub/sub 和 akka.net。我们目前没有任何问题，也没有预期需要并发控制。
我们拥有的是几个基本的工作流程，它们是数据分析、操作和结果的持久性：
第 1 步）捕获要完成的工作（即哪些对象需要做一些工作）
步骤 2) 执行该工作负载并产生结果
步骤 3) 保存结果
使用传统的 pub/sub 这似乎相当容易。每个步骤都有微服务，在每个步骤结束时推送一条消息，其中包含下一步所需的数据（或更多可能有用的点数据）。使用任何自消息队列/主题/订阅软件，这提供了一个很好的能力：
1) 在地理上将负载分布在世界各地到源数据所在的位置
2）增加订阅增加吞吐量的“工人”数量
3) 推动可以支持以最小的学习曲线连接“工人”的想法的核心
4）任何组件（或组件的一组工作人员）在工作流的下方有/有一个队列，其中消息排队并等待所述组件重新联机（即使整个组件断开连接）
5）添加新的组件来做一些新的和不同的事情，就像注册一个主题的新订阅一样简单。
这一切都是开箱即用的轻松快乐......假设这里遵循了合理的聚合和有界上下文模式。我不是在寻求如何编写好的分布式代码的建议，我在寻找如何部署它、支持它、调试 rouge/missing/corrupt 消息等。这就是我想知道 Akka.net 提供什么的原因。
我已经看到有 Akka.net clustering 。它可能还没有准备好生产，但我最好了解它可以/可以为我们做什么。
所以我的主要问题是：
1) 消息在到达之前存储在哪里？只要发布者可以访问消息传递总线/软件端点，任何此类软件都将存储并保存消息，等待订阅者连接并获取它的消息（关于订阅已经注册的明显假设，因此消息排队等待它）。Akka.net 集群如何处理所有这些？
2) Akka.net 集群中的这些队列和邮箱的操作支持有哪些工具？哪些工具可以让操作员深入了解邮箱中已接收但等待处理的内容，以及存在哪些工具可用于查看已“发布”和尚未“接收”的内容？大多数竞争的 Pub/Sub 软件都有操作工具，所以我在这里寻找一些比较。
3) 你如何调试 rouge、丢失或损坏的消息。我们都知道我们应该信任我们的软件，但是一条坏消息会导致系统失控，那么我该如何从系统中弹出一条坏消息呢？我如何修改一条消息，使其行为不同，因为业务需要在凌晨 3:30 修复某些内容？我如何用“它在系统中并且它正在等待接收”或“它已经收到并且就在邮箱中”来回答“我的消息在哪里”？
4) 如果一个组件出现 HARD（回收、硬件故障等等），什么会恢复邮箱、队列等？任何实际正在处理的消息都有可接受的丢失容忍度，但是邮箱中的 1000 条消息丢失不是那么容忍的，有什么持久性和容忍度？
5）我所做的轻量级审查似乎主张在您的软件中构建一个主管模式来编组消息（我猜是管理和释放并发锁？）。鉴于并发在这里不是问题，您支持什么开箱即用的发布/订阅机制，这不是两个（或代码中内部定义的 x）组件之间的基本消息远程处理？在大多数 pub/sub 软件中再次使用订阅和主题，您的第一个对象会推送一条消息（它是中心的，因此它是一个潜在的单点故障）但该组件（也没有任何其他代码）必须知道什么会使用该消息。它的扩展必杀技比较了我们手动将消息从一个对象推送到下一个对象（以及下一个对象）的旧学校方式，为同一消息必须去的每个新类重建或重新编译。我渴望不必构建我们自己的消息路由器。
6) 当特定组件的所有实例都脱机时（比如上面的步骤 3），什么会记住实际上有一些东西需要排队并记住这些消息（比如从上面的步骤 2 中盲目推送的那些）？在其他软件中，在您删除订阅之前，消息会根据为 TTL 等定义的规则不断排队。为此提供了什么？