ローカルファーストソフトウェア

State(状態)

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

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

次に羽毛のような場合には、私の情報、私のレポジトリ情報、star数など様々な情報があるが、これらによってユーザーに見える画面が変わるため、これらをすべて'状態'と見ることができる。

より複雑な例として、ピグマのような例が挙げられる。画面上のすべての点、線、面灯グラフィックはすべて「状態」である。さらに、コラボレーション機能は私以外の他の人の状態まで共有する必要があります。

State & Data

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

Data is too far

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

Optimistic Update

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

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

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

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

Responsiveness Over Consistency

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

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

CAP theorem

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

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

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

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

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

CA

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

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

AP

Availability Over Consistency

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

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

CP

Consistency Over Availability

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

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

PACELC Theorem

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

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

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

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

LC

Latency & Consistency

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

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

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

Strong Consistency

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

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

Eventual Consistency

いつかは整合艦

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

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

以上がローカルファーストソフトウェアの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。