銀行間引き出しの失敗が分散取引に関する考えを引き起こした

シナリオ

皆さんはこんな状況に遭遇したことがあるでしょうか。たとえば、ATM でお金を引き出すとき、1,000 元を引き出そうとすると、まずシステムによって 1,000 元が差し引かれ、その後 ATM からお金が吐き出されます。しかし、ATMに問題がある場合は、お金が引き落とされただけで、引き出されていないことがわかります。初めてこの問題に遭遇したとき、私はとても心配しました。複数の銀行から3,000元を引き出しましたが、テキストメッセージでお金が引き落とされたことを知らせるメッセージが届きましたが、お金は引き落とされていませんでした。そこで、助けを求めてカウンターに行こうとしたとき、お金が返金されたことを示す別の取引リマインダーが携帯電話に届きました。

[[278573]]

この事件は、データの一貫性について考えるきっかけとなりました。

資金処理リンク全体の経験に基づくと、一般的なプロセスは次のようになります。

シナリオ分析

実際の光景がこの絵に描いた通りであれば、いくつかの問題が生じるだろう

• 銀行 A は銀行 B のリモート インターフェイスを同期的に呼び出して、金額を引き落とします。インターフェース処理に時間がかかったり、ネットワーク障害が発生したりした場合は、ブロック時間が長くなります。そうすると、ユーザーは ATM ページがぐるぐる回っているように感じるでしょう。
• 引き出しが失敗すると、銀行 A のローカル取引テーブルのステータスが「4 引き出し失敗」に変更され、銀行 B のインターフェースが同期的に呼び出され、差し引かれた 3,000 元がロールバックされます。ロールバックが失敗した場合、ユーザーのお金は差し引かれますが、現金は引き出されません。

リモートインターフェースの非同期呼び出し

特定のパフォーマンス要件を持つサードパーティの呼び出しおよびプロセスでは、同期メソッドを使用しないでください。そこで最初のプロセスを非同期に変換します

非同期処理については、以前決済業務をしていたときにこうしていました

銀行 A は銀行 B のインターフェースを呼び出し、非同期メッセージ キューを導入し、すべてのトランザクション命令をメッセージ キューに直接送信して非同期処理を行います。指示を受け取って実行した後、銀行Bは

httpプロトコルは結果を銀行Aに書き戻す

失敗した引き出しのデータロールバック

解決策が導入された後にどのような問題を引き起こすかを心配するのではなく、まずは元々の問題を解決しましょう。

ATM が現金を引き出すことに失敗した場合、取引をロールバックする必要があります。上の図によれば、実際にはデータの一貫性の問題があり、トランザクション記録テーブルにはトランザクションが失敗したことを記録する必要があり、

お金を口座に戻すこと。この一貫性の問題は、実際には分散トランザクションの問題と呼ばれています。

分散トランザクション問題は分散データ一貫性問題とも呼ばれる

実際、分散アーキテクチャでは、分散トランザクションの問題は非常に一般的な問題です。よくあることなので、解決策があるはずです。ここで彼のさまざまな解決策について詳しく述べるつもりはありませんが、それらについてお話ししたいと思います。

建築的思考

まず、データベース トランザクションは ACID 特性を満たすことがわかります。

• 原子性（A）
• 一貫性（C）
• 隔離（I）;
• 持続性（D）

これら 4 つの特性のうち、一貫性は最も基本的な特性であり、他の 3 つの特性は一貫性を確保するために存在します。

分散シナリオでは、この単一データベース トランザクションは無意味です。

分散シナリオにおけるトランザクション一貫性スキーム

分散アーキテクチャでは、TCC（トランザクション補償）、信頼性メッセージに基づく結果整合性、2pcプロトコルに基づく強力な整合性など、一貫性の問題に対する多くの解決策があります。

多くのミドルウェアの一貫性プロトコルには、paxos や Raft などのアルゴリズムがあります。自分で確認してみてください。

前述したように、分散トランザクションの問題は分散アーキテクチャでは非常によく発生します。したがって、市場には多くのソリューションが存在します。つまり、ここには2つの概念が関わっているのです

• 1つは強い一貫性、もう1つは弱い一貫性です

いわゆる強い一貫性とは、ノード間でデータの強い一貫性を確保し、同時に成功するか、同時に失敗するかのいずれかです。

いわゆる弱い一貫性は、実際には最終的な一貫性の一種です。

キャップとベース

強い一貫性と弱い一貫性の違いは何ですか? また、システムにどのような影響がありますか?分析してみましょう。

CAP 定理、ブリューワーの定理とも呼ばれます。分散システム (分散トランザクションだけではない) を設計するアーキテクトにとって、CAP は入門理論となります。

1.C (一貫性):特定のクライアントの場合、読み取り操作は最新の書き込み操作を返します。異なるノードに分散されたデータについて、あるノードでデータが更新された場合、他のノードで最新のデータを読み取ることができる場合、それを強力な一貫性と呼びます。特定のノードがデータの読み取りに失敗した場合、分散不整合と呼ばれます。

2.A (可用性):障害のないノードは、妥当な時間内に妥当な応答 (エラーやタイムアウトではない) を返します。可用性の鍵となるのは、適切な時間と適切な応答の 2 つです。

合理的な時間とは、リクエストを無期限にブロックすることはできず、応答は合理的な時間内に提供されるべきであることを意味します。適切な応答とは、システムが明確な結果を返し、その結果が正しいことを意味します。

3.P (パーティション耐性):ネットワークパーティションが発生してもシステムは動作を継続できます。たとえば、クラスター内に複数のマシンがあり、そのうちの 1 台のマシンにネットワークの問題が発生しても、クラスターは正常に動作します。

CAP に詳しい人なら誰でも、分散システムではネットワークの信頼性が 100% 確保できず、パーティショニングは実際には避けられない現象であるため、これら 3 つは共存できないことを知っています。

CA を選択して P を放棄した場合、分割が発生したときに一貫性を確保するために、この時点で要求を拒否する必要がありますが、A はそれを許可しません。したがって、理論上、分散システムでは CA アーキテクチャを選択することは不可能であり、CP または AP アーキテクチャのみを選択できます。

CP の場合、可用性を放棄し、一貫性とパーティション耐性を追求します。

AP の場合、一貫性 (ここでの一貫性は強い一貫性を指します) を放棄し、パーティション耐性と可用性を追求することが、多くの分散システム設計の選択肢となります。後続のBASEもAPに基づいて拡張されます。

BASE は、Basically Available、Soft state、Eventually Consistent の 3 つのフレーズの略語であり、CAP の AP の拡張です。

• 基本的な可用性: 分散システムに障害が発生した場合、コア機能の可用性を確保するために、利用可能な機能の一部が失われることが許容されます。
• ソフト状態: システム内の中間状態の存在を許可しますが、システムの可用性には影響しません。ここでは、CAP の不一致について言及しています。
• 最終的な一貫性: 最終的な一貫性とは、一定期間が経過すると、すべてのノード データが一貫した状態になることを意味します。

BASE は、CAP における理論上のネットワーク遅延がないという問題を解決します。 BASE はソフト ステートおよび結果整合性を使用して、遅延後の一貫性を保証します。

インターネット企業にとって、ユーザー エクスペリエンスは最も重要なため、強力な一貫性によって生じる障害を回避するために、結果整合性ソリューションを使用してデータ一貫性の問題を解決します。より一般的に使用されるものは、ローカル メッセージ テーブル + 非同期キューと信頼性メッセージ キューに基づいており、最終的な一貫性のソリューションを実現します。

撤退失敗シナリオの改修

理論的な準備に基づいて、撤退の論理を考え、変換することができます

これでこのセッションは終わりですか？実はまだ

データの最終的な一貫性を確保するには、信頼性の高いメッセージ キューを使用するだけでは不十分です。メッセージ キュー自体の信頼性に問題がある場合、データの不整合の問題も発生します。

そのため、メッセージの処理状況を記録するローカルメッセージテーブルをAバンク側に作成するのが一般的です。次に、スケジュールされたタスクを使用してメッセージテーブルをポーリングし、最終的なデータの一貫性を実現します。

メッセージテーブルの設計

メッセージ テーブルには、トランザクションに必要なビジネス フィールドと、メッセージの再送信用に設計された補助フィールドが含まれています。

• ID 取引シリアル番号
• ステータス 取引ステータス
• lastUpdateTime 最終更新時刻