私は Azure Service Bus を初めて使用し、メッセージをキューに入れるためのトランザクション戦略を確立しようとしています。SQL Azure は MSDTC をサポートしていないため、分散型の TransactionScope を使用することはできません。したがって、データベース トランザクションを手動で処理できる Unit of Work があります。
問題は、TransactionScope を使用してデータベースと Azure Service Bus の両方の操作を処理している人しか見つけられないことです。TransactionScope を使用せずに Service Bus でトランザクションを実現する他の魔法の方法はありますか?
ありがとう。
クラウド ホスティングや azure Service Bus などのサービスを使用する場合は、2 フェーズ コミット (2PC) または分散トランザクション (DTC) をあきらめることを検討する必要があります。
代わりに、リソースごとのトランザクション (つまり、SQL コマンドのトランザクションまたは Service Bus 操作のトランザクション) を慎重に使用してください。そして、そのリソース境界を越えるトランザクションを避けてください。
次に、ワークフロー管理とエラー補正のために、信頼できるメッセージングとサガなどのパターンを使用して、これらのリソース/コンポーネントの操作をまとめることができます。そしてそこからスケールアウト。
クラウドで 2PC を使用するのは、さまざまな理由から困難です(ただし、不可能ではありません。IaaS を使用することはできます)。
DTC によって実装されている 2PC は、コーディネーターとそのログ、およびコーディネーターへの接続性が非常に高可用性であることに効果的に依存しています。また、すべての関係者が適切な方法で前向きな結果を得るために協力することにも依存します。そのためには、フェールオーバー クラスターで DTC を実行する必要があります。これは、システム全体のアキレス腱であり、すべてのトランザクションは DTC がそれをクリアすることに依存しているためです。
ここで、2PC トランザクションを一連のメッセージ/アクションおよび補償として考える方法の良い例を引用します。
2PC トランザクションの代表的な例は、銀行口座振替です。ある口座から引き落とし、別の口座に入金します。
これら 2 つの操作は一緒に成功または失敗する必要があります。これは、2PC トランザクションを説明するために非常に一般的に使用される例です。
問題は、それが実際に機能する方法ではないということです。ある銀行口座から別の銀行口座に送金することは、他の多くの口座に影響を与えるかなり複雑な作業です。さらに重要なことに、これは同期的な失敗/成功のシナリオではありません。
代わりに、会計原則が適用されます (驚き!)。送金が開始されると、たとえばオンライン バンキングでは、送金は会計システムに送信するためのメッセージの形式で記録され、借方は表示された残高に影響する「保留中」の取引としてアカウントに記録されます。
ユーザーの観点からは、トランザクションは「完了」していますが、実際にはまだ何も起こっていません。最終的に、会計システムはメッセージを受け取り、送金の実行を開始します。これにより、多くの場合、一連の操作が発生します。その多くは、清算口座への予約や他の銀行への送金の通知など、さらなるメッセージを生成します。
ここでの原則は、すべての進歩が前向きであるということです。何らかの技術的な理由で操作が機能しない場合は、技術的な理由が解決されたら再試行できます。
ビジネス上の理由で操作が失敗した場合、操作は中止できますが、前の作業を全滅させるのではなく、前の作業の逆を行うことによって中止できます。アカウントが貸方記入された場合、その貸方は同じ金額の借方記入で無効になります。
一部のタイプの失敗したトランザクションでは、「逆」操作は完全に対称的ではない可能性がありますが、ペナルティ料金を課すなどの追加のアクションが発生する可能性があります。
実際、経理では、あらゆる作業を全滅させることは違法です。「削除」と「更新」は刑務所に行き着く素晴らしい方法です。