私は分散 JBoss アプリケーションを設計しようとしていますが、今日の午後、何人かの同僚が CAP 定理、特にその「P」(パーティショニング) 部分について話しているのを耳にしました。彼らは、クラスター パーティション、ネットワーク パーティション、仮想パーティションなど、さまざまなパーティション タイプにどのように適用されるかについて話していました。
ネットワーク パーティションについての私の理解では、ネットワークを 2 つ以上の分離された部分に断片化する意図的な設計であるため、個々の断片の 1 つまたは複数の機能停止を処理できます。クラスタ パーティションはどのようにこのモデルに適合するか (つまり、CAP に関連するか)、「仮想」パーティションとは何ですか?!?
JBoss アプリをクラスタリングするときに、これらのいずれかを考慮する必要があるかどうか、また、そうする場合は、そのような考慮事項からどこから始めればよいかを考えています。前もって感謝します！
定理によれば、一貫性、可用性、およびアーティション耐性の3つCAPすべてを一度に達成することはできません。CAP
私の解釈では、を選択した場合、アプリが必ずしも永久に失われるわけではありませんAC+P。CAPアプリは、さまざまな時点で任意のペアを持つように設計できます。そして、あなたはあなたのどちらのペアCAPが最も多くの時間を持ちたいかを決める必要があります。
JBossクラスターのコンテキストでは、アップグレード/メンテナンス作業中にプライマリパーティションの代わりにそれを交換するために分離されたスタンバイセカンダリパーティションをセットアップできます。この方法では、メイン時間中に両方のパーティションを使用していC+Aないため、ほとんど使用できません。P今、あなたはあなたのアプリをアップグレードする時が来たと決めました、あなたにはどんなオプションがありますか？CまたはのいずれかAを一時的に変更できますP。つまり、パーティションを交換する（lose C）か、クラスター全体を停止する（lose A）ことができます。
もちろん、CAPメインタイムの他の組み合わせを選択することもできます。これは、アプリでどのSLAがOKかによって異なります。より人気のあるものはC+AとA+Pです。
CAP 定理の分割許容度は理論的な概念であり、具体的な概念ではありません。これは、システム全体が通信障害を処理する能力を指します。ノードを意図的に分離することを意味するものではありません。
CAP 定理自体は、Web サービスの観点から次のように述べています。
通信障害が発生しやすいネットワークでは、すべてのリクエストへの応答を保証するアトミックな読み取り/書き込み共有メモリを Web サービスで実装することは不可能です。
データベースに支えられた Web サービスの場合、共有メモリを実装しようとしていないため、実際には CAP 定理について心配する必要はありません。データベースがそれを行います。アプリケーションでライブ状態を維持する場合は、CAP 定理について心配する必要があります。その状態は、アトミックに (一貫して)、確実に (有効に)、維持したい読み取り/書き込みメモリを表すためcですa。ノード (pアーティション トレラント)。
複数のノードのデータベースに支えられている場合、データベース自体が CAP 定理に対処する必要があります。デプロイされた HA ソリューションは、通信障害を処理するためにさまざまなトレードオフを行います。たとえば、MongoDB レプリカ セットは、大多数のノードに接続されていないノードにマスター ステータスを強制的に放棄させることで、可用性をトレードオフします。悪条件でのデータベースの動作を理解し、それらがアプリケーションの要件と一致していることを確認してください。