4

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

意見 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番目が正しいと思います。何が間違っていて何が正しいのかを明確にしてください。それがなぜなのかという事実を与えることも素晴らしいでしょう。

4

1 に答える 1

4

4番目のステートメントは正しいですが、あなたが読んでいる方法ではないかもしれません. 2PC では、コーディネーターに障害が発生すると、システムは進行できなくなります。したがって、Paxos のようなフォールト トレラントなプロトコルを使用することが望ましい場合がよくあります (たとえば、 Gray と Lamportを参照)。これにより、障害が発生したときにシステムを安全に進行させることができます。

意見 3 は、Spanner ペーパーの残りの部分と照らし合わせて読む必要があります。著者は、分散データベースで効率的なトランザクションを可能にするシステムを開発したと述べており、それがシステムのユーザーにとって適切なデフォルトのトレードオフであると考えています。Spanner がそれを行う方法については、論文で詳しく説明されているので、読む価値があります。Spanner は、シリアル化可能なトランザクションを実装するために本質的に必要とされる調整を整理するための単なる 1 つの方法 (確かに賢い方法です) であることに注意してください。調整の限界を調べる 1 つの方法については、 Gilbert と Lynchを参照してください)。

意見 2 は一般的な信念であり、現実世界の分散システムにおけるトランザクション セマンティクスの可用性と豊富さの間には実際にトレードオフがあります。しかし、現在の研究では、これらのトレードオフが過去に描かれてきたほど深刻ではないことが明らかになっています。研究の方向性の 1 つについては、Peter Bailis によるこの講演を参照してください。厳密な意味で真の直列化可能性または線形化可能性が必要な場合は、それらを達成するために調整の特定の下限に従う必要があります。

意見1は技術的には真実ですが、あなたが引用した方法ではあまり役に立ちません. 2PC はある意味では最適ですが、可用性のトレードオフのため単純に実装されることはめったにありません。これらのトレードオフに対処しようとする多くのアドホックな試みは、不適切なプロトコルにつながります。Paxos や Raft のような他のものは、多少の複雑さを犠牲にして問題に対処することに成功しています。

于 2014-04-08T04:45:30.420 に答える