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事務的例子。

問題在於 - 那根本不是它真正起作用的方式。從一個銀行賬戶獲得資金到另一個銀行賬戶是一件相當複雜的事情，涉及大量其他賬戶。更重要的是，這不是一個同步失敗聯盟/成功聯盟的情況。

相反，會計原則適用（驚喜！）。轉帳啓動後，假設在網上銀行中，轉賬以消息的形式記錄，以便提交到會計系統中，借記在賬戶中記錄爲影響所顯示餘額的「待處理」交易。

從用戶的角度來看，交易是'完成'的，但事實上並沒有發生任何事情。最終，會計系統會收到信息並開始執行轉賬，這往往會導致一系列的操作，其中許多會產生更多的信息，包括預約結算賬戶和通知其他銀行的轉賬。

這裏的原則是所有的進展都是前進的。如果某項操作因某些技術原因而不起作用，則一旦技術原因解決，就可以重試該操作。

如果由於商業原因而導致操作失敗，可以中止操作 - 但不能通過消除先前的工作，而是通過與之前的工作相反。如果一個賬戶被記入貸方，那麼這個貸方將被扣除相同金額的借方。

對於某些類型的失敗交易，「反向」操作可能不完全對稱，但可能會導致額外操作，例如收取罰款費用。

事實上，在會計中，殲滅任何工作都是非法的 - '刪除'和'更新'是最終進入監獄的好方法。