Azure服务总线和事务

Question

我是Azure Service Bus的新手，我正在尝试建立用于排队消息的事务策略。由于SQL Azure不支持MSDTC，因此不支持MSDTC，因此无法使用它。因此，我有一个可以手动处理数据库事务的工作单元。

问题是我只能找到使用TransactionScope来处理数据库和Azure Service Bus操作的人员。在不使用TransactionScope的情况下，还有其他神奇的方法可以在Service Bus上实现事务吗？

谢谢。

Answer 1

如果您将使用云托管或 Azure 服务总线之类的服务，您应该开始考虑放弃两阶段提交 (2PC) 或分布式事务 (DTC)。

相反，请谨慎使用每个资源的事务（即 SQL 命令的事务或服务总线操作的事务）。并避免跨越资源边界的事务。

然后，您可以使用可靠的消息传递和模式（例如 sagas 等）将这些资源/组件操作编织在一起，以进行工作流管理和错误补偿。并从那里向外扩展。

由于各种原因，云中的 2PC 很难（但并非不可能，您仍然可以使用 IaaS）。

由 DTC 实现的 2PC 有效地依赖于协调器及其日志和与协调器的连接，以实现非常高的可用性。它还取决于所有各方以权宜之计为取得积极成果而合作。为此，您需要在故障转移集群中运行 DTC，因为它是整个系统的致命弱点，任何事务都依赖于 DTC 清除它。

我将在这里引用一个很好的例子，说明如何将 2PC 事务视为一系列消息/操作和补偿

2PC 交易的规范示例是银行账户转账。您借记一个帐户并贷记另一个帐户。

这两个操作需要同时成功或失败，否则你要么在创造金钱，要么在摧毁金钱（顺便说一句，这是非法的）。所以这是一个非常常用的例子来说明 2PC 事务。

问题是——这根本不是它真正起作用的方式。将钱从一个银行账户转移到另一个银行账户是一件相当复杂的事情，涉及到大量其他账户。更重要的是，这不是同步失败/成功的场景。

相反，会计原则适用（惊喜！）。当转账开始时，假设在网上银行，转账以提交到会计系统的消息的形式记录，借方作为影响显示余额的“待处理”交易记录在帐户中。

从用户的角度来看，交易已经“完成”，但实际上什么也没有发生。最终，会计系统将收到消息并开始执行转账，这通常会导致一系列操作，其中许多会产生进一步的消息，包括记入清算账户并通知另一家银行转账。

这里的原则是所有的进步都是向前的。如果某个操作由于某种技术原因不起作用，则可以在解决技术原因后重试。

如果操作因业务原因失败，则可以中止操作——但不是通过取消先前的工作，而是通过执行与先前工作相反的操作。如果一个帐户被记入贷方，则该贷方将通过相同金额的借方取消。

对于某些类型的失败交易，“逆”操作可能不是完全对称的，但可能会导致额外的操作，例如征收罚款。

事实上，在会计中，消灭任何工作都是非法的——“删除”和“更新”是最终入狱的好方法。