分散トランザクション:佐賀データの一貫性

分散トランザクションの実装

  1. 二次コミットプロトコル(二相コミットプロトコル)、三次のコミットプロトコル(三相コミットプロトコル)とのPaxosアルゴリズムがあります。
  2. X / OpenのDTPモデル(1994)は、アプリケーションプログラム(AP)、トランザクションマネージャ(TM)、リソースマネージャ(RM)、通信リソース管理(CRM)は、4つの部分を含みます。一般的に、共通のトランザクション・マネージャ(TM)は、トランザクション・ミドルウェアであり、共通のリソース・マネージャ(RM)はデータベースである、共通の通信リソース管理(CRM)は、メッセージング・ミドルウェアです。二次及び三次コミットプロトコルは、プロトコルは、この考えに基づいて導出されるコミット。
  3. Paxosアルゴリズム。
  4. 佐賀で実現します。

二次提出

  1. 準備段階(投票フェーズ)と第二段階:提出段階(実行ステージ)2つの段階第一段階があります。
  2. 準備段階では、他の参加者へのコーディネーターによって取引と情報の伝達、そして、彼らはその帰りを待って、トランザクションをコミットし、できれば尋ねました。
  3. フェーズコミット限り、参加者のいずれかが返すために失敗したとして、そのトランザクションコーディネータは、すべての参加者をロールバックする要求を送信し、割り込み、参加者はロールバックします。
  4. 問題:
    1. 同期ブロッキング問題。実行中は、すべての参加ノードは、トランザクションタイプをブロックしています。ときは公共資源の参加者の所持、およびその他のサードパーティ製のアクセス・ノードのパブリックリソースは、状態をブロックしています。
    2. 単一障害点。そのための重要コーディネーター、一度コーディネーターに失敗しました。参加者はそれをブロックしています。特に、第二段階では、コーディネータは、すべてのプレイヤーが業務リソースのロックされた状態で残っている、失敗し、トランザクション操作を完了し続けることができません。(それがコーディネータハングしている場合、コーディネータは再選されてもよいが、参加者のコーディネーターのダウンタイムが遮断状態に問題によって引き起こされるので、解決することができません)
    3. データの不整合。ステージに二相コミットプロトコル、コーディネータは、参加者をコミットする要求を送信した後、ローカルネットワークが異常発生やコーディネーターが要求処理をコミット送信に障害が発生した、参加者の一部のみが得られる。この時間は、コミット要求を受信しました。コミット要求後にこの部分参加で操作することを約束します。しかし、機械の他の部分は要求を受信して​​いないトランザクションがコミットコミット実行することができません。そこで、データの矛盾の現象を生じさせる全体の分散システム。
    4. 第二段階は、問題を解決することはできません。後にコーディネーターをコミットして、メッセージをダウン送信し、受信のみ、このメッセージの参加者もダウンしています。その後も、選挙プロトコルによって、新たなコーディネーターコーディネーターを作成し、事務のこの状態は、誰がトランザクションが既に提出されたかどうか知りません、不明です。

三次の提出

  1. 2PC 2に再び3PC準備段階、そうCanCommit、プリコミット、DoCommit三つの段階を提出する3つの段階があります。
  2. CanCommit:コーディネーターが含む業務を要求し、参加者がトランザクションをコミットした後、その戻りを待つかどうかを尋ねました。
  3. プリコミット:限り、任意の参加者があったように、第3の布割り込み操作に、トランザクションをエラーやタイムアウトを返します。第三段階の正常復帰を実行する場合はトランザクションがコミットされます。
  4. DoCommit:操作を受けたが中断され、その後、ロールバックを実行するためにそれらを可能にするために、すべての参加者に割り込み要求を送信します。
  5. 問題:
    1. デフォルトのコミットを実行する人、失敗2PCの単一のポイントへの相対3PC主な問題、そして一度参加者は、コーディネーターからのタイムリーな情報を受け取ることができないので、混雑を減らします。そして、それはブロックされた国政とリソースで開催されていません。ネットワーク上の理由のために、コーディネーターはタイムリーな応答が参加者によって受信されない送ら中止、しかし、この機構は、データの整合性の問題を引き起こす可能性があり、参加者はタイムアウトを待った後、コミット操作を実行します。データの不整合が、この間に存在し、他のバックと参加者ロールabortコマンドを受け取りました。
  • ヒント:それはプロトコルまたは三相二相コミットされているかどうか、2PCと3PCを知ることは、完全に分散一貫性の問題を解決できないコミット。

複雑なPaxosアルゴリズム - インターネットはPaxosアルゴリズム書かれた記事がたくさんあったが、ここでそれらを繰り返す簡単に紹介する必要はありません

  1. 解決するために、Paxosアルゴリズムは、究極の一貫性です。これは、2つの役割=>提案者の受信者が含まれています
  2. 例えば、パクシはどのようにこれらのデータノードが合意に達するために作るために、クラスタが複数のノードがあると?二つの主要な段階での具体的なアプローチ:
  3. 最初のステージは選挙で、提案は提案されていません。この段階で、私たち(複数のノード- 接收者から提议者選出された指導者は、ここで使用された提案、作るために私たちをリードする序列号選挙(高いシリアル番号、投票する資格が高い)より資格が誰であるかを識別することを。
  4. 第2段階は、主に第一段階の結果、提案選出されたノードの明確な受け入れ、かつ明確に提案内容に基づいています。
  • ここでは序列号、それは非常に重要ですが、どの段階、小さなシーケンス番号に関係なく、彼の選挙は拒否されます。第一段階では、一回接受者の選挙の前に受け入れた提议者提案、その後、戻ってきて、これがあること接受者提议者も、最初の選挙の位相が、その提案を修正することを強制しても、その後、彼は選出された指導者たちの前に提案の第二段階に移ります指導者たちの前に提案は、あなたの意見が収束するよう努めています。あなたは場合は接受者、以前に任意の提案を受けて、新たに選出されたことをしていない提议者自分自身が提案した前方に置くことができます。

参考:それは非常によく、ほとんど第二の例を知っている原則の最初の記事は、記事を理解することは非常に簡単です

  1. Paxosアルゴリズム分散システム
  2. Paxosアルゴリズムを説明する方法平野のですか?

佐賀(未完)

要件と制限
  1. ネットワーク要求に起因する分散システムでは、このようなパワー佐賀・コールなどのサービスをサポートする必要性を遅らせる可能性があります。複数の呼び出しの結果であるサガは同じによって引き起こされます。
  2. 唯一のACDを保証し、データの分離を保証するものではありません。
    1. セマンティックデータの矛盾現れるリソースを操作しながら、
    2. 同時に、演算結果データカバレッジを操作します
    3. 誤読を引き起こす前に、データ処理、佐賀追加の読み取り、修飾されていないデータを変更するようなダーティ読み出し、
    4. ファジーリード、すなわち、データの読み出し時に、不整合が二度読み取ら引き起こし、佐賀のデータを変更します
    5. 解決策:セッションに参加し、リソースが操作をシリアル化できることを確実にするためのメカニズムをロックする運用レベルからスタート。また、あなたは、運用レベルでの資源のこの部分を分離するために行くことができ、最終的に事業活動の過程で現在の状況をタイムリーを読み取ることによって、最新のアップデートを入手することができます。
  3. とき複数のトランザクション佐賀、トランザクションの実行エラーが発生し、どのように我々は、効果的なフォールバックを確保することができますか?
  4. フォワード・リカバリー:佐賀総務マネージャーの調節を介して取引が成功した場合、自動再試行回数を設定することで、参照するか、手動で再試行します。
  5. バックフォールバック:補足イベントの添加手動ように、各マイクロサービスの失敗後の補償機構。
  6. 振り付け佐賀トランザクション:追加します

佐賀・ソリューションズのChoerodon(豚メロ) - カフカ付き

  1. サービスは、すべてのSagaTask Managerへの登録サービスを開始すると佐賀では、佐賀豚メロは、トランザクションマネージャとしてオーケストレーターが割り当てられます。インスタンスは佐賀を開始すると、サービス消費者は積極的にこれに対応するポーリングデータにより佐賀に引っ張られ、および対応するサービスロジックを実行してもよいです。実行状態は、画面に表示するには、トランザクション・マネージャで表示することができます。
  2. ここで冪等性を達成するために、インスタンスを実行することによって記録されるSagaTaskの実装、次回はそのようなインスタンスがある場合、実行を生成しない場合には、各インスタンスのイベントに記録されます。
  3. A及びマイクロサービスのサービスを含むBは、特定の時間にCデータサービスに変更する必要がある場合、これは、2つを生成する:データ分離溶液など、単一のトランザクション管理サービスに還元されます佐賀データ。Cは佐賀に、これらのデータを引っ張って、データベース操作を実行するようにした後(ここでプロセスデータベースを単離するためにデータに相当します)
  4. 豚のメロは、現在、フォワード・リカバリ戦略を実施しています。場合は、その後の改善戦略が共有する時間に良くなります。
  5. 振付取引:追加します
参考:

ソリューションのマイクロサービスデータChoerodon豚メロプラットフォームの一貫性:ドンファン

おすすめ

転載: juejin.im/post/5d6a066af265da03b31be515