分散型トランザクションの華麗な進化 | 京東物流技術チーム

分散トランザクションに関しては、誰もが見知らぬ人ではありません。実際の業務では、柔軟な分散トランザクションが使用されることが多くなってきていますが、今日は、進化の過程である柔軟な分散トランザクションともいえる、業務で使用されるいくつかの柔軟な分散トランザクションのシナリオと実装方法を簡単に紹介します。

1. 発信者は保証します

このメソッドはビジネスそのものでの使用に適しており、メソッド内のタスクのロジックで例外が発生した場合、メソッド全体が異常となり、呼び出し元がリトライします。この方法は外部システムの相互作用には適していません。そうでない場合、自分自身の運命を他人の手に委ねる危険な行為となります。

上記の呼び出し図では、内部アプリケーション APP1 と APP2 の間で、APP1 のメソッドメソッド 1 が APP2 のメソッド 2 メソッドを呼び出し、メソッド 2 には分散トランザクションロジックが含まれています。分散トランザクションのロジックが異常な場合、メソッド 2 メソッドは失敗するか異常をスローします。、method1 が失敗または例外の戻り値を受け取った後、method2 が正常に実行されることを確認するために、method2 の呼び出しを再試行する必要があります。Method2 自体は、ロジック内の成功したロジックが再度呼び出されたときに正しく処理されることを確認する必要があります。

@DistributedTransaction
method2(){
    //write DB
    //send msg
    //RPC invoke
}

この方法は業務での使用を誰にでも推奨するものではなく、分散トランザクションの正当性を確保する目的でのみ使用できますが、Javaの仕様上、例外制御処理に属するためあまり標準化されていません。。同時に、分散トランザクションのロジックがローカルライブラリの作成、メッセージの送信、または RPC リモート呼び出しである場合、大規模なトランザクションを避けるために、トランザクションとメッセージ送信または RPC 呼び出しをトランザクションメソッドに組み込むことは一般に推奨されません。

2. ビジネステーブルをスキャンするスケジュールされたタスク

このシナリオは主に、トラフィックが少なく、ビジネスシナリオが 1 つしかないシナリオ、またはビジネスが検証段階にある場合に使用され、ビジネスの価値を迅速に検証するために、ビジネステーブルを直接タスクテーブルとして使用し、作成を回避します。複数のテーブル。ローカルトランザクションでビジネステーブルを書き込んだ後、トランザクションを正常に送信できます。スケジュールされたタスクを通じてビジネステーブルの増分データをクエリし、スケジュールされたタスク内の他のビジネスロジックを処理します。

@Transaction
void method1(){
    //write DB1 Bueiness Table
    //other business Logic
}

void method2(){
    //查询DB1中的Bueiness Table，时间从上次任务开始执行的时间开始
    //处理自身的业务逻辑
}

このソリューションは通常、暫定的なソリューションとして使用され、最終的な業務量が増加した後、次のローカルタスクリストソリューションにアップグレードされます。

3. ローカルタスクリスト

これは典型的な分散トランザクションソリューションです。つまり、ビジネスライブラリでは、タスクテーブルが同期的に作成されます。ビジネステーブルとタスクテーブルはローカルトランザクションに同時に書き込まれ、スケジュールされたタスクが定期的にタスクテーブルにクエリを実行し、タスクを読み取り、ビジネスロジックの要件に従って処理します。

ビジネステーブルとタスクテーブルはデータベース内にあり、データベースのトランザクションコントローラがトランザクションを実装します。アプリケーションで別のスケジュールされたタスクを開始すると、スケジュールされたタスクはタスクテーブルにクエリを実行し、タスクテーブル内の新しいタスクをキャプチャして、スケジュールされたタスクが実行する必要があるビジネスロジックを実行します。

@Transaction
void method1(){
    //write DB1 Bueiness Table
    //write DB1 Task Table
}

void method2(){
    //定时查询DB1中的Task Table
    //任务抓取后执行自身的业务逻辑
}

このソリューションを実際に使用する場合は、ソリューションの使いやすさを決定するタイミングタスクの安定性に特別な注意を払う必要があります。ビジネスへの影響を避けるために、スケジュールされたタスクの実行を監視して、問題にできるだけ早く対処できるようにすることをお勧めします。

4. コンポーネントの抽出

現在、Java 言語開発チームでは、ほとんどのフレームワークが Spring をベースにしているため、SpringEvent 非同期イベントをベースにした小さなコンポーネントパッケージを作成できます。主なアイデアは、トランザクションで非同期イベントを送信することです。非同期イベントの送信が成功すると、トランザクションの送信は終了します。非同期イベントの送信に失敗すると、非同期タスクはローカルデータベースに渡され、トランザクションが再度送信されます。次に、スケジュールされたタスク実装を通じてタスクテーブルからタスクがフェッチされます。

このソリューションは SpringEvent 非同期イベントをコンポーネントとしてベースにしており、SpringEvent 非同期イベントが例外を送信すると、非同期タスクの信頼性を確保するためにローカルタスクテーブルにダウングレードされます。コンポーネントとしてパッケージ化されていない場合でも、実際の作業ではこのソリューションを使用することをお勧めします。

@Transaction
void method1(){
    //业务数据写入DB成功
    try{
    //发送SpringEvent事件
    }catch(Exception ex){
    //写入本地任务表
    }
}

void method2(){
    //接收事件或定时任务的数据执行业务逻辑
}

もちろん、Spring フレームワークを使用しないプロジェクトでも構いませんので、上記の考え方を参考に、使用するフレームワークに合わせて調整してください。ことわざにあるように、「考え方が間違っていない限り、困難よりも解決策は常にあります。」

著者: JD Logistics Liao Zongxiong

出典: JD Cloud 開発者コミュニティによる Yuanqishuo Tech からの転載。出典を明記してください