大众运输具有内置的"输出"实现，我认为这将处理我希望克服的大多数问题/挑战，但是我找不到很多文档在我寻找的细节中描述了它的功能。在观看视频之后，很多这些问题都出现了，乌迪·达汉(Udi Dahan(解释了如何在没有分布式交易的情况下处理可靠的消息传递(https://vimeo.com/111998645(。
- 在尝试将消息发送到队列时可能发生的内存量输出操作失败吗？因此，例如：消费者生成了3个收集在输出框中的消息。消费者毫无问题地完成。发出框中的收集消息开始处理
- 如果从某种原因处理收集的消息时存在网络问题(或其他问题(，而消息2未能发送消息2和3的消息？有任何重试政策吗？
- 如果成功添加到队列中，但未成功标记为在发件箱中发送的消息，该怎么办？会有另一种尝试将消息发送到队列的尝试吗？
- 假设输出框是否会重试将消息发送给队列，如果某种故障是否保证了在尝试之间保证一致的消息ID？具有一致的消息ID对于删除措施至关重要，以确保我们不会多次处理相同的消息。
- 当消息消耗消息时，是否会发生任何删除措施？(这与1.C联系在一起(
- 每个消费者如何为每个消费者进行大众运输轨道处理的记录？存储引擎是否照顾这一责任？
- 是否有任何类型的"交易"暴露于消费者中，使您可以在发出框中清除收集的消息而不会抛出异常，或者抛出例外情况的唯一方法可以回滚发出式发动机？
- 在消费者之外生成的消息又有什么方法可以在发出框中收集回滚消息(例如：WebAPI控制器操作(？
- 是否有建议使用质量运输的DTC功能，而不是oferbox或VICE反之亦然？
- 当前大规模运输没有可以在过程崩溃中幸存下来的量子箱实现。是否有包含此类功能的计划？是否有跟踪的路线图？
-
内存ONBOX DEFERS DEFER任何消息发送/发布/响应呼叫，直到消费者完成所有处理为止。这包括常规的消费者和传说。消费者要做的最后一件事是发送/发布任何递延消息，然后确认传入的消息(并从队列中删除(。话虽如此，您的问题中的大多数项目都不相关，因为它不是写给数据库的消息，然后再处理它们。
-
否
- 否
- 不要使用DTC，甚至不支持.NET Core
- 没有计划，路线图上没有任何计划
正如您一开始所说的，内存的量子箱将处理99.9％的案件。精心设计的传奇和支持服务可以将其推动甚至更高，从而确保了势力并最终成功的命令(或事件(处理。除了今天之外的任何事物，通常都可以支持设计良好的系统，并且只会通过额外的依赖性创造出太多的复杂性。