プログレッシブWebアプリの秘密パート2

記事の最初の部分を見逃した人のために： ここにいます。 まあ、いつものように、ハブラハブル、こんにちは。 PWAのトピックと基本的な同期アルゴリズムの研究を続けます（始めたものをやめないでください）。 最後の部分では、条件付きアプリケーションがサーバーから記事を要求し、最新の資料のみを受け取り、記事の変更と削除を監視し、これらすべてを正しく処理できるという事実になりました。 それはすべて、デルタの計算を通して機能しました：アプリケーションが持っているものとサーバーに保存されているものとの違い。







このパートでは、上記の理論を実装するためのさまざまな特定のスキームを研究し、それらの長所と短所について説明します。 それでは、始める前に、目的のアルゴリズムの要件を説明しましょう。



同じIDを持つ2つのオブジェクトがあり、それらを区別できるようにする必要があります。どちらが新しいかを教えてください。 つまり、どのオブジェクトが関連するかを判断します。 2つではなく、3、5、または10であり、本質的に何も変わらない場合は、関連度で並べ替えて、オブジェクトの最新の新鮮な関連性を選択できるようにする必要があります。 実際、バージョン管理システムが必要です。

インクリメントカウンター

最初の最も明白なアイデアは、簡単な整数カウンターを作成することです。 「バージョン1」、「バージョン2」、...「バージョン100500」-わかりました。







このことの主な利点は、コンピューターだけでなく、人にとってもすべてが明確であることです。 つまり、データベースに手を入れると、どの記事が関連し、どの記事が関連していないかをすぐに理解できます。 それで問題は何ですか？



記事は複数の人が編集できると想像してください。 1つはサーバー側にあり、もう1つはクライアント側にあります。 記事の初版は、インデックス「バージョン1」で発行されました。 次に、サーバーは「バージョン2」インデックスを使用して編集済みドキュメントを作成します。クライアント...と「バージョン2」もクライアントで作成されます。「1」の後に「2」が続き、クライアントはサーバーに何があるかを知らなかったためです：現時点で利用可能な接続がなかったとしましょう。



現在、「バージョン2」インデックスを持つ2つのドキュメントがありますが、それらが同じであるかどうかはわかりません。 そして、クライアントにとって（そしてサーバーにとっても）両方のバージョンは正当であるように見えます-バージョンカウンターは同じであり、同期する必要はありません。 では、バージョンをより詳細な言語で記述する必要がありますか？

タイムスタンプ

同じIDを持つドキュメントのバージョンを区別するために、カウンターだけでなく、記事が保存された時間も記録できます。 2016年10月11日、12：30：57、または単に111016123057のいずれであっても、番号が一意であり、記事の特定の状態を表すことが重要です。

タイムスタンプの正しい説明の詳細には触れません。一部のタイプはPCでの処理に便利で、一部のタイプはユーザーに便利です。 自分のやり方でやりたい場合は、 ISO 8601標準を使用することをお勧めします。







最後に何がありますか？ 同じ記事に異なるタイムスタンプがあり、どのバージョンが新しいかを簡単に理解できます。 時計は前進しているだけなので、タイムスタンプの次の各バージョンは前のものよりも正確に長くなります。 かどうか？



記事を読み続ける前に、プログラマーが時間の仕組みを知っていると思うときに攻撃するこの素晴らしいレーキのコレクションを見てください。 彼には2番目のパートもあります。



ありふれた例。 あなたはバーで魅力的な女の子に会い、電話で彼女の番号を書きました。 2桁の数字を間違えないように十分飲んだので、もう一度確認することをお勧めします。 番号を編集し、正しいバージョンを保存して、さよならを言います。 連絡先にはタイムスタンプがあり、クラウドとの同期が成功したため、帰宅途中に電話をなくしても電話は残ります。 かどうか？



上記のリンクから既に「レーキ」を開いている場合は、2番目の番号を保存しているときにノートブックにどの程度のことが起こるかを理解できます。 実質的に無限のリソースを持つGoogleのような巨人でさえ、時には...時間関連の問題に遭遇します。



ノートブックの更新プロセスでは、何でも起こり得ます。 最初のバージョンをタイプミスと同期してから、バム！ -電話はサーバーと同期し、1分前に時計を設定しました。 または、真夜中に正確にヒットすると、夏時間がオンになります。 IPhoneには、1月1日に設定されたアラームにまだ問題があります。 一般的に、私たちが望むように単純なタイムスタンプを信頼することはできません-私たちの場合、あなたは女の子の電話を紛失していたでしょう。必要ありません。 しかし、クライアントとサーバーで時間がずれることもあります...



私たちの考えを要約すると、特定のシナリオが何であれ、小さなプロジェクトや大規模なシステムで問題が発生する可能性があります。 両方のタイムスタンプが同じデバイスで生成された場合でも、単純なタイムスタンプを信頼し、2つのオブジェクトのエディションのシーケンスを保証することはできません。この動作はデータ損失につながる可能性があります。 そしてこれは、タイムスタンプを改善する必要があることを意味します。 しかし、その前に、もう1つの問題の原因、つまり競合を考慮する必要があります。

競合を解決します

競合を説明するために、例を少し拡張する必要があります。 興味深い記事の読者のクラブだけでなく、読者と作家のクラブがあると想像してください。 ハブラハブのように。



私たちがすでに持っており、機能しているもの：ある種のレガシーコードがあります。 サーバーは作成者に問い合わせることができ、そのアプリケーションは新規および/または変更された記事を送信できます。ユーザーは必要なものだけを送信するため、ユーザーは同じ方法でユーザーに新しい資料をリクエストしてトラフィックを節約できます。 また、条件付きのエディター、モデレーター、および管理者がいて、記事の内容を修正できます。



エディターが記事を読み、タイプミスを見つけて修正し、サーバーに変更を送信しました。 ほぼ同時期に、著者は記事に更新を追加し、コード例を使用してリポジトリを更新したと述べ、注意深い読者にコメントと示されたエラーに感謝し、サーバーに送信しました。



これらのイベントが両方とも数秒で発生した場合はどうなりますか？ どの編集が後で行われ、どの編集がより早く行われたか（送信前にサーバーとクロックを同期し、考えられる問題と考えられない問題をすべてチェックした）を100％知っていても、タイプミスの記事またはコードにエラーのある記事があります。











実際、これは矛盾です。 この場合、記事のバージョンの競合。

どうする？

あなたのことは知りませんが、対立は好きではありません。 そして実生活ではそれらを避けようとします。 確かに、人生の中でこれがしばしば行われる場合、IT部門では絶えず対立に対処する必要があります。 紛争は非常にひどいものです。 また、分散システムなどもあります。 このフレーズには多くの異なる解釈がありますが、私たちの場合は次のようになります：任意のネットワークで接続された2台以上のコンピューターがあり、すべてのコンピューターのデータセットを同じようにしようとしている そして今、最もおいしい-ネットワーク要素はいつでも失敗する可能性があります。 失敗のシナリオは多数あり、すべてを予測することは困難です。 また、2つのデバイスと1つのサーバーが存在する基本的なシナリオでも、動作させる必要のある分散システムが既にあります。 これが私たちがやることです。 小さく始めましょう。うまく構築されたソリューションは問題なくスケーリングできます。



したがって、1台のコンピューターでドキュメントを編集する場合、既にわかっているように、競合は非常に悪く、分散コンピューティングの競合は自然な状態です。 これは、それらを無視したり、これが起こらないふりをしたりできることを意味するのではなく、競合を受け入れてメカニズムの一部にする必要があることを意味します。



競合の発生方法については既に説明しました（例では競合を作成しました）。それを解決する方法を見てみましょう。 前の例で、タイプミスが2番目の段落にあり、資料への追加が記事の最後に追加されたとします。







たとえば、記事が段落として保存されている場合、異なる段落の2つの編集を更新し、これらの変更を2つの別個のエンティティとして扱うことができます。 プログラマーにとって、これはマージ（またはロシア語の場合はマージ）と呼ばれます。 gitのようなすべての種類の場合、これは一般的で非常に便利なメカニズムです。 この場合、コンピューターはそれ自体で競合することなく記事の最終バージョンを収集します。



タスクを複雑にしましょう。 著者と編集者が同時にタイプミスに気づき、異なる修正を行ったとします。 著者は同義語を選択することを決定し、単語を置き換えました。編集者は既存の1文字または2文字のみを修正しました。 そして、両方がほぼ同時に変更をサーバーに送信しました。 これで、コンピューターはどのバージョンが正しいかを判断できなくなります。 どうする



既にお気付きのように、1つのグローバルタスクをますます小さな部分に分割し、同期の問題についての理解を深めています。 記事がありました-今段落。 段落は行に分割できます。 行-言葉で。 遅かれ早かれ、エンティティへの分割の合理的な限界に達しますが、それでも矛盾が生じます。 さらに、コンピューターだけでは解決できない競合を正確に把握できます。前の例は、これを明確に確認するものです。



人をそのような問題につなげるだけです。AIはまだ発明されていないので、現時点では他に方法はありません。 最終的に、進化は人に生き残り、紛争を解決することを教えただけだったので、コンピュータの意味で紛争をそれほど恐れることはないと思う。 ああ、タイムスタンプに戻って改善する時が来ました。

ベクトル時計

タイムスタンプに関する問題の解決策を探し始めるとすぐに、たとえば、 Lamportタイムスタンプの形式の ベクトルクロックについて言及します。 タイムスタンプにベクトルクロックを適用すると、 論理クロックと呼ばれるものが得られます。 タイムスタンプだけでなく、オブジェクトに論理クロックも使用する場合、どの編集が先に行われ、どの編集が後で行われたかを確実に計算できます。 いいね！ それは何か他のものに対処するために残っています。







編集者がタイプミスを同時に修正し、作成者が素材を追加する場合について話したときのことを覚えていますか？ 上記のシステムとのこの競合を修正しました：論理クロック+タイムスタンプ。 しかし、編集内容が同じテキストに関連している場合、またはさらに面白いことに、編集結果が同じテキストになっている場合はどうでしょうか？ ここでは何のトリックも役立ちません、競合は残ります。 つまり、一見、競合はありません。結果を比較し、余分なものを捨てて、それがビジネスです。 しかし、結果を解決するのではなく、さらに先へ進み、衝突を起こさないとしたらどうでしょうか？



今、この問題は少し手に負えないように見えますが、それは一例です。後で実際にそのような問題に遭遇したとき、1つの同期サーバーではなく、サーバークラスター全体、数千、数千のクライアントで作業します。実用的なソリューションの作成にも、将来のスケーリングにも問題はありませんでした。



退屈な作業をスキップして最後まで行かせてください。 一般に、コンテンツアドレス可能バージョンなどがあります。

コンテンツのアドレス指定可能なバージョン

同じ編集との競合を解決するために、このハックを使用します。 編集/オブジェクトの内容を取得し、ハッシュ関数を（同じMD5またはSHA-1を介して）実行し、ハッシュをバージョンとして使用します。 同一のソースデータは同一のハッシュを生成するため、同じ結果の編集は競合を引き起こしません。



確かに、これは一連の編集の問題を解決しませんが、今すぐ修正します。 まず、各更新でドキュメントを上書きする代わりに、ドキュメントのバージョンの順序付きリストを保持します。 ドキュメントの一部を更新すると、Content Adressable Versionがシートの上部に編集とともに記録されます。 これで、いつ、どのバージョンの編集が到着したかが正確にわかりました。 一般的に、このことは便利ですが、ドキュメントの編集とバリアントの数を保存するか、サーバーに転送するかを事前に決定する価値があります。 これがすべての理由だったことを覚えていますか？ アプリケーションを最適化するには、トラフィック量、メモリ使用量などを減らします。 したがって、実際の開発では、「持ち運ぶ」ために必要な編集の数を考えてください。一般に、10〜1000の数字が機能し、タスクの個人的な経験と知識、対象読者、およびアプリケーションが適切なものを選択する方法のみが機能します。



その結果、編集の履歴により多くのスペースを使用しますが、競合を回避する柔軟なシステムがあります。



このような複雑なものをフェンスして「不要な」データを保存するスペースを無駄にするよりも、同じベクタークロックを使用して競合を解決する方が簡単に思えるかもしれませんが、1台のサーバーではなくクラスターがあればすぐにすべてが変更されます独立したリクエスト処理サーバーと、すべてのユーザーに一貫したデータを提供する必要性。

競合を効果的に保存する

最後に、最後の問題を解決する必要があります。 1人のユーザーが同じマテリアルに順次変更を加えると、バージョン履歴は次のようになります（簡単にするため、ハッシュではなく素数を使用します）。







5つのバージョンがあります。 ここで人為的に競合を作成します。4以降のバージョンのリストでは、5番目と6番目のバージョンの競合が発生します。







これらのバージョンは競合していることがわかっています。 しかし、この競合を解決する代わりに、別の競合を作成したらどうなるでしょうか？ 上記のシートにさらにいくつかの値を記述してください。







現在、バージョン「6」と「7」の競合があり、この競合自体はバージョン「5」と競合しています。 誰かuprls？ いや 実際、改訂履歴はバージョンツリーに変わります。 いくつかの利点があります。

1. 競合を効率的な方法で保存します。
   
   
2. 競合を再帰的に解決できます。競合する編集やブランチがいくつあっても、競合が発生していない状態にいつでも戻ることができます。
   
   

すべてをまとめる

要約すると。 同期の多くの（場合によっては明白なように見える）側面を分解して明確にしました。 ここで、すべての開発を行ってそれらを組み合わせた場合に何が起こったのかを見てみましょう。 上記のアルゴリズムの重要な点を以下に示しますが、これらの問題をすでに調べているため、これがすべて行われる理由については説明しません。

1. AとBの2つのデバイスがあります。 それらの情報を同期する必要があります（AからB）。

2.同期チェックポイントがある場合は、読み取ります。

3.デバイスAから更新情報の読み取りを開始します。 チェックポイントが存在する場合はチェックポイントから読み取り、存在しない場合は最初から読み取ります。

• Id / versionという形式の各ペアを検討します。
  
  
• これが削除の場合は、デバイスBでローカルに削除を覚えておいてください。
  
  
• Bにそのようなペアがなかった場合は、Aから読み取り、Bにローカルに保存します。
  
  
• 更新チェックポイントをAとBに保存します。
  
  

4.バージョンのリストから、現在のバージョンがBの最新バージョンの直接の継続であるかどうかを確認します。

• その場合、デバイスBに保存します。
  
  
• そうでない場合は、競合を作成します。
  
  

それだけです

最後までありがとう。 アプリケーションをスケーリングするときに、信頼性が高く、大きな苦痛にならない、効果的で効果的な同期を初めて開発することがいかに難しいかを理解してください。 さて、同期自体のために同期については説明しませんでしたが、PWAで同期を適用するという文脈で、習得した知識を実践します。



ちなみに、最初はお伝えしませんでしたが、 CouchDBレプリケーションプロトコルを視覚レベルで「ソート」しました。このすべてが考慮されました。これにより、任意の数のユーザーとのp2pに基づいた透過的な同期を作成でき、上記のすべてのシナリオが考慮されます。 同様に、このプロトコルはCouchDBデータベースの一部であるため、サーバーで完全に機能します。 ブラウザおよびローカルマシンでは、PouchDBを使用できます。これは、同じプロトコルを実装しているが、JavaScriptとnode.jsにある同様の製品です。 したがって、CouchDB + PouchDBバンドルを使用して、必要なすべてのユーザーケースをカバーできます。 もちろん、携帯電話では、これらのテクノロジーはそれぞれiOSおよびAndroid用のCouchbase MobileおよびCloudant Syncの形式でも提示されます。 したがって、最初の投稿の冒頭で述べたように：







完成品を使用してください。 ただし、遅かれ早かれ、独自の技術を作成するために、テクノロジーを完全に理解することを忘れないでください。 それだけです