NserviceBus 6.x基于传输事务级别的消息管道方案

Question

我正在阅读documentation几次，但仍然不清楚基于事务级别发生错误时消息管道是怎样的。

上图显示了具有三个处理程序的管道，这些处理程序首先将命令发送到第二个和第三个订阅事件。当处理程序2处理业务逻辑并开始发布事件时发生错误。基于运输交易水平会发生什么？我的假设列在下面。

1. 交易范围级别
   总线回滚事务。所有流程都基于可恢复性计划（立即重试和延迟重试）从处理程序1开始。如果可恢复性计划完成，则发生故障回滚并将消息移至错误队列。消息可以从例如重试服务脉冲，它从处理程序1启动管道，前面描述了步骤。
2. 传输事务 - 使用Receive发送原子事务 基于可恢复性计划从处理程序2开始处理。如果可恢复性计划完成但失败消息将移至错误队列。消息可以从例如重试服务脉冲，从处理程序2开始管道，前面描述了步骤。

Answer 1

这在很大程度上取决于您的运输和文章中描述的DTC。 如果您正在使用DTC，则您的假设在1和2中是正确的，因此它将与使用DTC的MSMQ或SQL服务器传输一起使用。

（顺便说一句，如果您认为可以改进文章以使其更清晰，您可以提交拉取请求）

HTH

Answer 2

我不确定你的情况是什么。根据肖恩的回答和你的其他问题，我也会尝试回答。

通常会将消息发送到端点。每个端点都有一个传入队列。该消息将分派给一个或多个处理程序。通常这只是一个。

对于分布式事务（通常是Windows中的MSDTC），它取决于您使用哪些资源应该回滚错误。 MSMQ和SQL Server支持MSDTC，因此理论上应该可行。在出错时，所有内容都将回滚，包括收到的消息，SQL事务和传出消息。你会有一个干净的状态。

SMTP不支持交易，因此如果您发送电子邮件并且交易回滚，则无论如何都会发送电子邮件。因此，如果您重试该邮件，将再次发送该电子邮件。

AtomicSendsWithReceive表示传输仅参与事务。这意味着接收和发送消息将在错误时回滚。但是在SQL Server（或任何其他资源）中完成的任何操作都不会被回滚。

这是在每个端点内设置的，并适用于每个传入的消息。由于通过队列发送消息是完全异步的，因此，如果您在不同端点之间发送消息或将每个后续消息发送到同一端点，则无关紧要。

在NServiceBus中，有一个处理消息的管道。它验证要使用的事务，要执行的处理程序等。如果您正在讨论这个问题，那么处理程序无法“订阅”另一个处理程序。

如果您正在谈论消息流，其中一个处理程序发送或发布新消息，那么我上面写的所有内容都适用。