State(狀態(tài))

ウェブがますます発展し、ユーザーと相互作用する要素、見られる要素が多くなるようになった。これらの要素はユーザーが見る畫面を変えます。畫面を変化させるものを「狀態(tài)」と定義することができる。

例えばランディングページのような情報(bào)性ウェブページの場合に'狀態(tài)'といえるのは見せる情報(bào)一つだ。

次に羽毛のような場合には、私の情報(bào)、私のレポジトリ情報(bào)、star數(shù)など様々な情報(bào)があるが、これらによってユーザーに見える畫面が変わるため、これらをすべて'狀態(tài)'と見ることができる。

より複雑な例として、ピグマのような例が挙げられる。畫面上のすべての點(diǎn)、線、面燈グラフィックはすべて「狀態(tài)」である。さらに、コラボレーション機(jī)能は私以外の他の人の狀態(tài)まで共有する必要があります。

State & Data

狀態(tài)はすべてデータだ。ユーザーに関する情報(bào)、ユーザーのカスタマイズ情報(bào)などすべてどこかに保存されているデータであり、このデータはすぐにユーザーが見る畫面の狀態(tài)になる。通常、このデータとはサーバーにSingle Source of Truthとして保存されます。どのウェブサイトにログインしたら、そのサイトのサーバーのusersテーブルに1行で保存されます。

Data is too far

最近のWebは複雑です。ボタンは數(shù)え切れないほど多く、一畫面に見せるデータも多い。時(shí)義性が重要な情報(bào)も多い。これらの狀態(tài)が変わるたびに、データの整合性のためにサーバーに行き來する必要があります。文書のように1分で「次のページ」だけを受け取れば良い場合には大きな問題にならない。しかし、ノッションのようにユーザーが引き続きデータを修正する場合なら大きな問題になる。ページで特性のようなものを設(shè)定するたびにロードしなければならないと中がひっくり返るだろう。

Optimistic Update

Instagramのようなソーシャルメディアサイトで「いいね」を押すことを考えてみよう。 「いいね！」をクリックするとサーバーに行き、私がその投稿を好きだったという情報(bào)を保存し、その投稿のいいね。

しかし、インスタグラムは0.001秒でアニメと一緒にいいねが押されてカウントが上がる。

これは、サーバーに情報(bào)が到達(dá)する前にクライアントの狀態(tài)を更新することで可能です。 「いいね」を押したデータがサーバーにうまく記録されるのではなく、クライアントの狀態(tài)を更新するのだ。ほとんどの場合、サーバーとの通信が成功するので、これを楽観的に成功すると判斷するのだ。

もちろん、サーバーに送信された要求が失敗することもあるので、失敗したときにクライアントの狀態(tài)をロールバックすることは気にしなければなりません。

Responsiveness Over Consistency

私が好きを押したかどうかをOptimisticに示すのは非常に合理的だ。しかし、私が押したときに他の人も押して良いが1つ以上増えた可能性がありますが、これはどのように処理するのだろうか。

これはただデータ整合性を少し無視することで簡単に解決になる。その投稿が人気の投稿であれば、私がポストを見るその間にいいです。これはちょうどそのソフトウェアのポリシーです。迅速な応答のために少しのデータ整合性は犠牲にすることです。

CAP theorem

分散システムの學(xué)問にはCAP理論がある。この理論は、分散システムを構(gòu)成するときにC、A、Pのうち最大2つしか取ることができないという理論です。

CはConsistencyで整合性だ。どのノードからデータを読み取ったのか、同じデータを読み取る必要があります。

Aは、Availabilityでどのノードが死んでいても、すべてのリクエストに応答できるのか。

Pは、Partition-toleranceで何ノードのネットワーク接続が切斷された場合に動作できるか、ネットワーク接続後に再び回復(fù)できるかである。

この理論によると、結(jié)局CA、AP、CPこの3つのシステムが可能だ。

CA

理論上は分散システムがCAを選ぶことができるが、ネットワーク接続が切れたら動作しないシステムは私たちは分散システムと呼んでいないことにした。

最終的に分散システムであれば、Pは保証されるべきです。

AP

Availability Over Consistency

いくつかのノードのネットワーク接続が失われたとき、すべてのノードがその値の最新の狀態(tài)について同意しなかったとしても、一度接続されているノードの値を下げるのだ。そのため、切斷されたノード間で最新のデータが一致しない可能性があります。しかし、ユーザーはまるで最新のデータを受け取るかのようにサービスを引き続き利用することができる。

代表的な例はソーシャルメディアです?，F(xiàn)実では起こらない法的なことだが、ヨーロッパにあるインスタグラムのノードとアジアの爐のネットワーク接続が切れてしまったと仮定しよう。アジアで接近するユーザーとヨーロッパで接近するユーザーが見るフォロー數(shù)、いいね數(shù)などはこの障害期間の間少し違っても大丈夫だ。しかし、機(jī)能はまだ動作するはずです。

CP

Consistency Over Availability

ネットワーク障害狀況に最新データについて確信がつかない狀況で、ユーザーの要求に応答しないシステムだ。

例は通常お金（取引）に関連するものだ。 50％割引するホテルの部屋が一つ殘った狀況でネットワーク斷絶が起きたとしよう。 APシステムでは両方とも部屋があるだろうし、予約を受けてオーバーブッキングを受けてしまう可能性がある。 CPシステムはこのデータの最新狀態(tài)については確信が持てないので、これに対する要求を延期させるか拒否する。

PACELC Theorem

CAP理論は実際にはPartitionの理論です。もしPartitionが起こったらAやCを選ぶべきだということだ。

しかし事実、普通の狀況の場合、Partitionは起こらない。そのような狀況で適用できる理論がPACELC理論である。

if(P) then(AC) else(LC)

つまり、Partitionの場合はACを考慮するか、またはLCを考慮するという意味である。

LC

Latency & Consistency

通常の狀況では、システムはLatencyとConsistencyをトレードオフします。途方もなく理論だが、実はこれはコンピュータ工學(xué)全般にわたる真理のようなものだ。

Trade offを考えるということは、この2つの基準(zhǔn)のある程度に妥協(xié)を見ることを意味する。

Latencyは遅いから速い程度を直感的に知ることができますが、Consistencyはどの程度を持つか直感的に知ることは難しい。

Strong Consistency

強(qiáng)い整合性は名前だけ聞いても感覚が取れる。どのノードにアクセスしても、無條件に同じデータを見る必要があります。つまり、すべてのノードが同じデータを持っていなければならない可能性があります。

銀行を考えてみるといいと思います。

Eventual Consistency

いつかは整合艦

という名前の整合性だ。ある変更點(diǎn)について同じ時(shí)刻 すべてのクライアントが同じ値を見るわけではないが、同期が終わった後は結(jié)局同じ値を見ることになるという意味だ。

したがって、ソフトウェアの特性によって、Latencyを犠牲にして整合性を取るのか、それとも迅速な応答のために整合性を犠牲にするのかが決定される。

以上がローカルファーストソフトウェアの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。