みなさん、こんにちは、私はアヒル午前：
今日は、マルチスレッドアプリケーションのシナリオは、総務春実際の共有です。
前は主に開始し、トランザクション（データベース・リンク、分離レベル、ThreadLocalのスレッド結合）の実行のために、原則について話しました。
https://blog.csdn.net/Angry_Mills/article/details/82502288
分析の実用的な観点から、次の。
次のシーンのデモコード住所：
https://gitee.com/fireduck_admin/demo-mutithread.git
1.シミュレーションのシナリオ
1.1メソッド追加されていないトランザクションの注釈の提出のマスタースレッドのトランザクション新しいスレッドの実施形態
のメインスレッドと子スレッドのトランザクションは、別途提出（子スレッドが提出され、メインスレッドを提出）
1.2を加えた例トランザクション注釈著者のマスタースレッドのトランザクション新しいスレッドの実施形態
のメインスレッドとサブにスレッドの業務に提出
注釈付きの唯一の方法な状況以下の点を考慮
1.3通常、異常な子スレッドのメインスレッド
新しいスレッド道を追加するサブスレッドのrunメソッドの面でトランザクション注釈なし、子スレッドが非トランザクションで実行された
ノートの1.4非同期使用springboot、メインスレッド、プラストランザクション・ノート、総務なしサブスレッドは指摘
メインスレッドと子スレッド総務とともに提出
トランザクションのメモなしで非同期ノートの1.5用途のspringboot、メインスレッドに加えて、取引のノート、サブスレッドを、サブスレッド例外
メインスレッドの子スレッドのトランザクションがあるコミットされていない
1.6ノートのspringboot、プラスメインスレッド総務ノートに加え、トランザクションサブスレッドコメント@Transactional（伝播= Propagation.REQUIRES_NEW）を使用して、非同期
メインスレッドとトランザクションは子スレッド提出された（子スレッドのスレッドが天皇を提出提出）
非同期コメントspringbootを使用して1.7、マスターをコメントスレッドの取引に加え、トランザクションサブスレッドのコメントを追加するには@Transactional（伝播= Propagation.REQUIRES_NEW）、異常な子スレッド
メインスレッドと子スレッドのトランザクションがあるコミットされていない
ノートの1.8非同期使用springboot、プラスメインスレッド総務ノート、サブスレッドプラストランザクションのアノテーション@トランザクション（伝播= P ropagation.REQUIRES_NEW）、メインスレッド異常
メインスレッドコミットされていませんそして、子スレッド総務提出します
要約。
非同期設定Propagation.REQUIRES_NEW、使用してノートメインスレッドと子スレッドは、実際には2つの異なるトランザクションがされて提出されました。
しかし、異常な子スレッドのために、しかし、2つはロールバックされます。異常なロールバックによる子スレッドは、これは問題ありません。一方で例外がメインスレッドに投げ、メインスレッドにもロールバックを行いました。
私たちは、と考えることができネストされている、例外はトランザクション全体のロールバック任意のサブスレッドの原因になりますマルチスレッドのトランザクション。
しかし、異常な実行トランザクションが直接提出されません場合は、子スレッドが、関係なく、メインスレッドの異常です。
2.実際のシーン
そのような場面に遭遇し、ユーザーが開始支払いと私たちは同期インタフェースされる前に、この時間にも問題があり、この時間は、サードパーティの支払いインタフェース（例えばアリペイなどのインタフェース）を要求します。
支払いので、非常に高速非同期コールバックより少ないデータ（見つけるために、注文番号を持つデータベースで、その結果、ストレージに提出されていないデータを）。
これは、非同期メソッドは、サードパーティのデータベースを呼び出す前に、インターフェイスがストレージ（サブスレッドのトランザクションコミットを）持っていることを保証するために主に行われていたに倉庫オペレーションを考えることは確かではありません行うにサービスを提供しています。
我々は1.7を超えるプラクティスを採用することができます。この時間は、メインスレッドの優先度よりも、子スレッドが提出しますが、場合でも、それは実行の特定のサブスレッドが速く、コールバックよりも保証することはできません。
改善された3。
一般的なサードパーティのコールバックインタフェースはタイムアウト時間を持って、彼はあなたが任意の論理処理を行うにはしたくありません。長いほど、受信したメッセージは、成功に返されます。
彼らは、非同期ビジネスロジックながら、成功したコールバックのリターンを受けた後、個別にメッセージ処理やサービスロジックを受信します。
この時間は、ストレージに入れていない場合は、コールバック固有の識別（注文番号とコールバックパラメータ）キャッシュに。
子スレッドの貯蔵後にも同様の操作を行い、そこに（コールバックを最初について説明されている）されている場合、クエリキャッシュ順序番号は、その後、非同期通知たinvoke手動コールバックパラメータを取得します。
もちろん、これはおそらく極端なケース、単にクエリを完了したコールバックメソッドで、同時にキャッシュ、単にストレージアクセスをキャッシュ/子スレッドを置きます。原因はまだキャッシュ順序番号に存在しています。
問題のこの非常に低い確率では、あなたが時間遅れ補償プログラムを（1時間1回）実行することができます。
