整合性モデルとレプリカキャッシュ

Consistency Model

Consistency Modelは、分散システムでどの程度のConsistencyを提供するかについての様々な規約である。以前のポストの中で、PACELC理論でLatencyとConsistencyをTrade offする内容があり、このTrade offによってどの程度のConsistencyを提供するかについての内容である。

以前のポストで取り上げたReplicacheも分散システムの一種だ。 ReplicacheはCausal Consistencyに従うと言われています。

ソース
Strict Consistency

常に時間順に値を読み取ることができるConsistencyである。値が書き込まれた後に発生するすべての読み取りは常にその値を読み取ります。これを満たすには2つの条件が必要です。すべてのノードが共有するグローバルクロックが存在し、それに同期する必要があり、Writeがすぐに実行される必要があります。

w(x)a: x に a という値を write, r(x)a: x から a という値を read

t 時間に w(x)a が 1 番ノードで発生し、t delta(0.0000000000000001s)の後に 2 番ノードで r(x) が発生したとき、2 番ノードは値 a を読み取らなければならない。 🎜>

同じt時間に操作が実行されないように、グローバルクロックが存在して操作を直列化しなければならず、書き込みが直ちに実行され、t delta時に書き込み値を読み取ることができるはずです。

しかし、これは実際に不可能なことです。したがって、Strict Consistencyは理論的に存在します。

以下の状況でStrict Consistencyに従うなら

正解は次のとおりです。

Sequential Consistency

Sequential Consistencyのキーキーワードは「Global Ordering」だ。すべての書き込み/読み取り操作は、単一の統合順序があるかのように動作する必要があります。また、各プロセス（クライアント）が行う操作は、その順番で実行しなければならない。

以下の場合、p3とp4はどのような値を読むことができますか？

下はStrict Consistencyと同じなのでSequential Consistencyも満足する。

以下はGlobal Orderingを見つけることができるので、Sequential Consistencyが正しい。

Global Ordering: w(x)a, r(x)a, w(x)b, r(x)b

しかし、以下の場合にはaがbより先に書かれたが後で読み取られる。このような場合はSequential Consistencyを満足しない。

Causal Consistency

Causalとは原因-結果関係を意味する。

"Happens-before(→)"

関係であることを理解することが重要です。 A→Bは、次の場合に成立する。

同じプロセス（クライアント）でAがBの前に発生する

1. Aの後にメッセージを送り、メッセージを受け取った方がBを遂行する。
2. A→B、B→CならA→Cです。
Causal Consistencyとは、この原因 - 結果関係がすべてのノードで一緒に見える規約です。

以下のケースはCausal Consistencyです。

ここで見つけることができる「Happens-before」関係は、w(x)a→r(x)a、w(x)b→r(x)b だけであり、これはすべてのプロセスが満足する。 P3がbを最初に読むのは大丈夫です。 2つの書き込み操作は独立しているため、w（x）a→w（x）bの原因 - 結果関係はないためです。

以下はCausal Consistencyを成立しません。理由はw(x)a→w(x)cの原因-結果関係が存在するが、P3でcがaより先に読まれるからである。

Eventual Consistency

Eventual（結局）一貫性を持つようになる規約だ。いつか書き込み操作がなく、ネットワークが安定すると、最終的にすべてのノードは同じ値を見ることになります。非常に有限の規約です。

Consistency in Replicache

ReplicacheはCausal Consistencyに従うという。これはもう少し強いCausal Consistencyなのですが、後で調べてみましょう。

以上が整合性モデルとレプリカキャッシュの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。