問題タブ [2phase-commit]

いくつかの記事を読んで混乱しました。

意見 1: 2PC は非常に効率的であり、最小限の数のメッセージが交換され、待ち時間が短い。出典: http://highscalability.com/paper-consensus-protocols-two-phase-commit

意見 2: 分散トランザクションを高レベルにスケーリングすることは非常に難しく、さらにスループットが低下します。2PC保証のACIDとして 複雑な協調アルゴリズムのため負担が大きい。出典: http://ivoroshilin.com/2014/03/18/distributed-transactions-and-scalability-issues-in-large-scale-distributed-systems/

意見 3: 「一部の作成者は、2 フェーズ コミットがもたらすパフォーマンスや可用性の問題のために、サポートするにはコストがかかりすぎると主張しています。アプリケーション プログラマーは、トランザクションの不足を常にコーディングするよりも、ボトルネックが発生したときにトランザクションの過剰使用によるパフォーマンスの問題に対処する方がよいと考えています。Paxos で 2 フェーズ コミットを実行すると、可用性の問題が軽減されます。」ソース: http://courses.cs.washington.edu/courses/csep552/13sp/lectures/6/spanner.pdf

意見 4: 2PC コーディネーターは、重要なシステムには受け入れられない単一障害点でもあります。私は、2PC コーディネーターがコーディネーターであると信じています。ソース: http://www.addsimplicity.com/adding_simplicity_an_engi/2006/12/2pc_or_not_2pc_.html

最初の 3 つの意見は互いに矛盾しています。4番目が正しいと思います。何が間違っていて何が正しいのかを明確にしてください。それがなぜなのかという事実を与えることも素晴らしいでしょう。

私はこれらの 2 つの技術についてかなり混乱しています。

1. これらの 2 つの技術の間に関係はありますか

2. これらの技術を実装した既存の一般的なオープン ソース ソフトウェアはありますか? Zookeeper が Paxos を実装していることは知っていますが、2 フェーズ コミットはどうですか?

分散トランザクションで RM (リソース マネージャー) として機能するには、DBMS は 2 フェーズ コミットを実装する必要があります。PostgreSQL と同様に、最初にローカル トランザクションを「事前コミット」するとき:

次にコミットします。

私の質問は: MS SQLServer はそのような機能をサポートしていますか?

Bean 管理トランザクションを持つ EJB タイマー (EJB 2.1) があります。

タイマー コードは、1 つのトランザクションで 2 つのリソースを処理するビジネス メソッドを呼び出します。1 つはデータベースで、もう 1 つは MQ キュー サーバーです。

使用するアプリケーション サーバーは Websphere Application Server 7 (WAS) です。2 つのリソース (データベースとキュー マネージャー) 間の整合性を確保するために、WAS で 2 フェーズ コミットをサポートするオプションを有効にしました。これは、データベース操作中に何らかの例外が発生した場合に、キューに投稿されたメッセージがデータベースのロールバックと共にロールバックされ、その逆も同様であることを保証するためです。

以下にフローを説明します。

Timer コードでタイムアウトが発生すると、DirectProcessor の startProcess() が呼び出されます。これがビジネス メソッドです。このメソッドには、同じクラスの createPostXMLMessage() へのメソッド呼び出しがある try ブロックがあります。これには、クラス PostMsg の別のメソッド postMessage() への呼び出しがあります。

問題は、createPostXMLMessage() メソッドでデータベース例外が発生した場合、データベース部分が正常にロールバックされても、以前に投稿されたメッセージがロールバックされないことです。助けてください。

ejb-jar.xml 内

https://en.wikipedia.org/wiki/Two-phase_commit_protocolの 2 フェーズ コミットの説明を参照しています。

コミット前フェーズで、両方のリソース マネージャーが賛成票を投じたとします。

トランザクション マネージャーが各リソース マネージャーに COMMIT メッセージを送信してコミットを開始し、そのうちの 1 つだけが ACK を返し、もう 1 つが ACK を返さない場合、トランザクション マネージャーは、コミットに成功した最初のリソース マネージャーから既にコミットされたトランザクションをどのようにロールバックしますか? ?

グローバル トランザクションが失敗したときに、トランザクションが一方のリソース マネージャーでコミットされ、もう一方のリソース マネージャーではコミットされない可能性はありませんか?

Mono で実行できる Linux 環境で WebAPI 2.2 を自己ホストしようとしています。問題は、分散トランザクションにトランザクション スコープを使用しているため、(DTC) Windows 以外のプラットフォームでサポートされていますか? また、DTC なしで 2pc を実装するための回避策または代替手段はありますか?

ZooKeeper Programmer's GuideのConsistency Guaranteesセクションでは、ZooKeeper が「Single System Image」を保証すると述べています。

クライアントには、接続先のサーバーに関係なく、サービスの同じビューが表示されます。

ZAB プロトコルによると、フォロワーの半分以上が提案を承認した場合にのみ、リーダーはトランザクションをコミットできます。したがって、すべてのフォロワーが同じステータスにあるとは限りません。

フォロワーが同じステータスにない場合、ZooKeeper はどのようにして「単一システム ステータス」を保証できますか?

参考文献:

• ZooKeeper のアトミック ブロードキャスト プロトコル: 理論と実践
• 単一システム イメージ