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

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

シナリオ

皆さんはこんな状況に遭遇したことがあるでしょうか。たとえば、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 最終更新時刻


<<:  クラウドコンピューティングの時代に、知っておくべき10のセキュリティ技術をご紹介します

>>:  TigerGraph が業界初のネイティブ グラフ データベース サービスを開始

推薦する

[クラウドネイティブ] Prometheus カスタムアラートルール

1. 概要 Prometheus 監視アラート ルールを作成することで、特定の Prometheus...

IBM、中国でBlue Cloud 6+1ソリューションを正式にリリース

2009 年 5 月 22 日、第 1 回中国クラウド コンピューティング カンファレンスが北京のチ...

情報公開ウェブサイトを最適化する方法についての簡単な説明

数日前、Shi Tou の友人が情報公開サイトを受け取り、QQ グループでそのようなサイトを最適化す...

無料のウェブサイトソースコードの使い方

2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますインターネ...

Agora が数百万人規模のリアルタイム大規模チャンネルインタラクション機能を開始

最近では、オンライン教育、スマートハードウェア、自動運転車、ライブストリーミング、セキュリティ監視、...

例は、ホットワードの代替思考が非常に重要であることを示している

ウェブサイトの最適化やオンライン マーケティングを行う際には、トラフィックは複数のチャネルから来るべ...

ウェブマスターは頻繁に更新される Baidu アルゴリズムにどのように対処するのでしょうか?

最近の百度アルゴリズムのアップデートにより、多くのウェブマスターの友人が百度の非人道性について不満を...

ホームページを数秒で収集し、18日以内に内部ページの日記を収集します

まず、具体的な動作例としてステンレスベルトのケースを取り上げます。まず、ユーザー分析ウェブサイトを作...

ウェブサイトのランキングに影響を与えるリンク分析要因の解釈

ウェブサイトのランキングに影響を与える要因は多数ありますが、外部リンクがウェブサイトのランキングに影...

曲頭条にはまだ突破のチャンスはあるのだろうか?

Qutoutiao は、新しい形式の情報閲覧を創造することに特化したソフトウェアです。モバイル アプ...

QuadraNet - $39/Q9300/8g メモリ/1T ハードディスク/15T トラフィック/5IPv4/ロサンゼルス

QuadraNet は時々現れて、ジャンクなものをいくつか出します。彼らによると、これは超低価格のサ...

インフルエンサーマーケティングがユーザー行動に与える影響に関する4つの心理的要因の分析

月収10万元の起業の夢を実現するミニプログラム起業支援プラン最近、人気番組「The Rap of C...

SUSE と Amazon Web Services が SAP クラウド イノベーションを加速する新たな戦略的パートナーシップを確立

SUSE と Amazon Web Services は新たな戦略的パートナーシップを確立し、顧客が...

タオバオストアの購買転換率に影響を与える致命的なポイント

少し前、多くの淘宝網の販売業者が張立氏を見つけ、自分の店舗の状況を調べるのを手伝ってほしいと頼んだ。...

私は転職の準備をしているので、SEOについての意見を述べたいと思います

私はいわゆるSEOの専門職に2年間従事してきました。何も知らないいわゆる外部リンクの専門家としてスタ...