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