分散トランザクション、このようにプレイできますか？

複数のデータを同時に操作する場合、そのデータの整合性と一貫性をどのように確保すればよいでしょうか?

回答: 取引は一般的な慣行です。

[[247728]]

例えば：

ユーザーが注文を行うと、残高テーブル、注文テーブル、取引テーブルを変更する必要があるため、次のような疑似コードが作成されます。

トランザクションを開始します。
 CURD テーブル t_account;例外ロールバック。
 CURD テーブル t_order;例外ロールバック。
 CURD テーブル t_flow;例外ロールバック。
専念;

• 残高テーブル、注文テーブル、フロー テーブルのすべての SQL 操作が成功した場合、すべてが送信されます。
• いずれかが失敗した場合は、すべてをロールバックします

データの整合性と一貫性を確保するためのトランザクション。

取引計画にはどのような潜在的な問題がある可能性がありますか?

回答: インターネットのビジネス特性により、大量のデータと大量の同時実行性では、システム パフォーマンスを向上させるためにデータベースの分割を頻繁に使用する必要があります。データベースが分割されている場合、残高、注文、取引は異なるデータベース、または異なるデータベース インスタンスに分散される可能性があります。この場合、データベースのネイティブ トランザクションを使用してデータの一貫性を確保することはできません。

高度な同時実行性と実装の容易さを備えた分散トランザクションは、業界ではまだ十分に解決されていない難しい問題です。それで、私たちに何ができるでしょうか?

A: 補償取引は一般的な慣行です。

補償取引とは何ですか？

回答：補償取引とは、業務側で逆の業務操作を実行する取引です。

例えば：

残高を変更するには、次のトランザクションを実行します。

 int Do_AccountT(uid, お金){
    トランザクションを開始します。
         //残高はこの金額だけ変わります
         uid の money を含む CURD テーブル t_account。
         anyException ロールバックは NO を返します。
    専念;
    YESを返します。
 } 
  

次に、残高を変更するには、補償トランザクションを次のようにします。

 int Compensate_AccountT(uid, お金){
         //お金の逆操作を行う
         Do_AccountT(uid, -1*money)を返す{
 }

同様に、注文操作の場合、トランザクションは次のようになります: Do_OrderT、新しい注文を追加します。

注文操作の場合、補正トランザクションは Compensate_OrderT であり、注文を削除します。

バランスと順序の一貫性を確保するための疑似コード:

 // 最初のトランザクションを実行する
intフラグ= Do_AccountT ();
 if(フラグ= YES ){
    //最初のトランザクションが成功したら、2番目のトランザクションを実行します
フラグ= Do_OrderT ();
    if(フラグ= YES ){
        // 2番目のトランザクションが成功した場合、それは成功します
        YESを返します。
    }
    それ以外{
        // 2番目のトランザクションが失敗した場合、最初のトランザクションの補正トランザクションを実行します
        補償アカウントT();
    }
 }

補償取引のデメリットは何ですか?

• 異なるビジネスでは異なる補償取引を作成する必要がありますが、これは普遍的ではありません。
• トランザクションの失敗に対する補償は考慮されません。
• ビジネス プロセスが複雑な場合、if/else は複数のレイヤーにネストされます。

ナレーション: 上記の例では、バランスと順序の一貫性のみを考慮しているため、2 * 2 = 4 つのブランチがあります。残高 + 注文 + トランザクションの一貫性を考慮すると、2*2*2=8 の if/else 分岐が発生し、複雑さが指数関数的に増加します。

他に一貫性を保つための簡単な実践方法はありますか?

回答: 複数のデータベース インスタンス上の複数のトランザクションの一貫性を確保するには、「コミット後の最適化」を実行します。

単一のデータベースでは、一貫性を確保するために次のような大規模なトランザクションが使用されます。

トランザクションを開始します。
 CURD テーブル t_account;例外ロールバック。
 CURD テーブル t_order;例外ロールバック。
 CURD テーブル t_flow;例外ロールバック。
専念;

複数のデータベースに分割された後、大きなトランザクションは次の 3 つの小さなトランザクションになります。

トランザクション1を開始します。
         //最初のライブラリトランザクション実行
         CURD テーブル t_account;例外ロールバック。
         …
 // 最初のデータベーストランザクションがコミットされる
コミット1; 
 
トランザクション2を開始します。
         //2番目のライブラリトランザクション実行
         CURD テーブル t_order;例外ロールバック。
         …
 // 2 番目のデータベース トランザクションのコミット
コミット2; 
 
トランザクション3を開始します。
         //3番目のライブラリトランザクション実行
         CURD テーブル t_flow;例外ロールバック。
         …
 // 3番目のデータベーストランザクションがコミットされる
コミット3;

ナレーション: これら 3 つのトランザクションは 3 つのデータベース、またはデータベースの 3 つの異なるインスタンスで発生することを再度思い出してください。

トランザクションは、実行と送信の 2 つのフェーズに分かれています。

• CURDの実行には長い時間がかかります
• コミットは非常に速く実行されます

したがって、実行プロセス全体のタイムラインは次のようになります。

• 最初のトランザクションの実行には 200 ミリ秒、コミットには 1 ミリ秒かかります。
• 2 番目のトランザクションは実行に 120 ミリ秒、コミットに 1 ミリ秒かかります。
• 3 番目のトランザクションは実行に 80 ミリ秒、コミットに 1 ミリ秒かかります。

どの時点で矛盾が生じるのでしょうか?

回答: 最初のトランザクションが正常に送信されてから最後のトランザクションが正常に送信されるまでの間に何らかの問題 (サーバーの再起動、データベースの異常など) が発生した場合、データの不整合が発生する可能性があります。

ナレーション: 上の図に示すように、最後の 202 ミリ秒以内に異常が発生し、不整合が生じています。

コミット後の最適化とは何ですか?

回答: トランザクションの実行と送信の順序が変更された場合、トランザクションは最初に実行され、最後に一緒に送信されます。

• 最初のトランザクションの実行には 200 ミリ秒かかり、2 番目のトランザクションには 120 ミリ秒かかり、3 番目のトランザクションには 80 ミリ秒かかります。
• 最初のトランザクションは 1 ミリ秒コミットし、2 番目のトランザクションは 1 ミリ秒コミットし、3 番目のトランザクションは 1 ミリ秒コミットします。

コミット後の最適化後、不整合はいつ発生しますか?

A: 質問に対する答えは前と同じです。最初のトランザクションが正常に送信されてから最後のトランザクションが正常に送信されるまでの間に何らかの問題 (サーバーの再起動、データベースの異常など) が発生した場合、データの不整合が発生する可能性があります。

ナレーション: 上の図に示すように、最後の 2 ミリ秒以内に異常が発生し、不整合が生じます。

違いや矛盾点は何でしょうか?

答え：

• シリアル トランザクション ソリューションでは、合計実行時間は 303 ミリ秒であり、最後の 202 ミリ秒の例外によって不整合が発生する可能性があります。
• 送信後の最適化ソリューションの合計実行時間も 303 ミリ秒ですが、不一致は最後の 2 ミリ秒の例外によって発生します。

データの一貫性の問題は完全に解決されていませんが、不整合の可能性は大幅に減少しています。

ナレーション: 上記の例では、確率は 100 分の 1 に減少します。

提出後の最適化の欠点は何ですか?

A: トランザクションのスループットに影響します。

• シリアル トランザクション スキームでは、最初のデータベース トランザクションがコミットされるとデータベース接続が解放されます。
• コミット後の最適化ソリューション: すべてのトランザクションが実行されるまで、すべてのデータベース接続は解放されません。

つまり、データベース接続にかかる時間が長くなり、システム全体のスループットが低下します。

要約する

分散トランザクション、2 つの一般的な方法:

• 報酬業務
• コミット後の最適化

バンドル

trx1.exec(); trx1.コミット();
 trx2.exec(); trx2.コミット();
 trx3.exec(); trx3.コミット();

最適化対象:

 trx1.exec(); trx2.exec(); trx3.exec();
 trx1.コミット(); trx2.コミット(); trx3.コミット();

この小さな変更 (コストは極めて低い) では、マルチデータベース分散トランザクションにおけるデータ一貫性の問題を完全に解決することはできませんが、スループットを犠牲にして、データの不整合の可能性を大幅に減らすことができます。

一貫性とスループットのトレードオフについては、ビジネス アーキテクトがトレードオフを慎重に検討する必要もあります。

ナレーション: 前にも言ったように、一般的なビジネス慣行から逸脱した建築設計は、ただの不正行為です。

結論よりもアイデアの方が重要です。誰もが恩恵を受けられることを願っています。

【この記事は51CTOコラムニスト「58 Shen Jian」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください