Azure 服务总线和事务

Question

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

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

谢谢。

Answer 1

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

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

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

云端2PC很难all sorts of reasons (但并非不可能，您仍然可以使用 IaaS)。

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

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

The grand canonical example for 2PC transactions is a bank account transfer. You debit one account and credit another.

These two operations need to succeed or fail together because otherwise you are either creating or destroying money (which is illegal, by the way). So that’s the example that’s very commonly used to illustrate 2PC transactions.

The catch is – that’s not how it really works, at all. Getting money from one bank account to another bank account is a fairly complicated affair that touches a ton of other accounts. More importantly, it’s not a synchronous fail-together/success-together scenario.

Instead, principles of accounting apply (surprise!). When a transfer is initiated, let’s say in online banking, the transfer is recorded in form of a message for submission into the accounting system and the debit is recorded in the account as a ‘pending’ transaction that affects the displayed balance.

From the user’s perspective, the transaction is ’done’, but factually nothing has happened, yet. Eventually, the accounting system will get the message and start performing the transfer, which often causes a cascade of operations, many of them yielding further messages, including booking into clearing accounts and notifying the other bank of the transfer.

The principle here is that all progress is forward. If an operation doesn’t work for some technical reason it can be retried once the technical reason is resolved.

If operation fails for a business reason, the operation can be aborted – but not by annihilating previous work, but by doing the inverse of previous work. If an account was credited, that credit is annulled with a debit of the same amount.

For some types of failed transactions, the ‘inverse’ operation may not be fully symmetric but may result in extra actions like imposing penalty fees.

In fact, in accounting, annihilating any work is illegal – ‘delete’ and ‘update’ are a great way to end up in prison.