Azure服务总线和事务

Question

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

问题是我只能找到使用TransactionScope来处理数据库和Azure服务总线操作的人员。在没有使用TransactionScope的情况下，是否有任何其他不可思议的方式在Service Bus上实现事务？

谢谢。

Answer 1

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

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

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

2PC在云中很难all sorts of reasons（但不是不可能，你仍然可以使用IaaS）。

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

我会quote这里怎么想的2PC事务的一系列的消息/动作一个很好的例子，并赔偿

盛大典型的例子为2PC交易是银行转帐。您可以借记一个帐户并另存一笔。

这两个操作需要成功或失败在一起，因为否则你要么创建或销毁钱（这是非法的，顺便说一句）。这就是常用于说明2PC事务的例子。

问题在于 - 那根本不是它真正起作用的方式。从一个银行账户获得资金到另一个银行账户是一件相当复杂的事情，涉及大量其他账户。更重要的是，这不是一个同步失败联盟/成功联盟的情况。

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

从用户的角度来看，交易是'完成'的，但事实上并没有发生任何事情。最终，会计系统会收到信息并开始执行转账，这往往会导致一系列的操作，其中许多会产生更多的信息，包括预约结算账户和通知其他银行的转账。

这里的原则是所有的进展都是前进的。如果某项操作因某些技术原因而不起作用，则一旦技术原因解决，就可以重试该操作。

如果由于商业原因而导致操作失败，可以中止操作 - 但不能通过消除先前的工作，而是通过与之前的工作相反。如果一个账户被记入贷方，那么这个贷方将被扣除相同金额的借方。

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

事实上，在会计中，歼灭任何工作都是非法的 - '删除'和'更新'是最终进入监狱的好方法。