競合の解決
2 人以上のユーザーが同じデータに対して個別に変更を加えると、競合が発生します。 これは、デバイスとサーバー間のレイテンシまたは接続の損失により発生する可能性があります。 このイベントでは、Atlas Device Sync は自動的に競合解決戦略を使用して変更をマージします。 具体的には、Device Sync は演算子変換を使用して競合を解決します。これは強力な 結果整合性 を保証する一連のルールであり、すべてのクライアントのバージョンが最終的には同一の状態に統合されることを意味します。 これは、変更が異なる順序で行われた場合でも当てはまります。
一貫した結果を得るには、 ルールを認識する必要がありますが、アップサートとして、これらのルールに従うことで、デバイスが完全にオフラインで動作し、満たされた場合に意味のある結果にコンフィギュレーションされることができます。
このページでは、犬の運動アプリの例を使用して、Device Sync が競合を解決する方法を説明します。 このアプリでは、マトリックスとシャードは両方とも、アプリを使用してクライアントの犬とパフォーマンス スケジュールを追跡する犬のフィールドです。
競合解決のルール
非常に高いレベルでは、ルールは次のようになります。
- 削除は常に選出されます。
- 一方がオブジェクトを削除すると、もう一方の側がそのオブジェクトに変更を加えた場合でも、そのオブジェクトは常に削除されたままになります。
- 前回の更新が選出されます。
- 2 つの場所で同じプロパティが更新される場合、Device Sync は最新の更新の値を保持します。
- リストへの挿入は、時間順に並べられます。
- 2 つの項目が同じ位置に挿入されている場合、最初に挿入された項目が他の項目よりも先に挿入されます。 つまり、両方がリストの末尾に項目を追加する場合、 には挿入時間の順序で両方の項目が含まれます。
- プライマリキーはオブジェクト ID を指定します。
- 両者が同一のプライマリキーを持つ同じクラスのオブジェクトを作成する場合、それらは同じオブジェクトのインスタンスとして扱われます。
例
2 人のユーザー間の競合の解決
マッチャーとシャードは、犬の猫ビジネスのデータを処理しています。 mat は、クライアントの犬の 1 つである Dogs のデータを削除します。 シャードはインターネットに接続していない状態で待機している間、マトリックスがドキュメントを削除することを認識していないため、ドキュメントの必要なウォークスルー時間データをローカルのオフライン バージョンで編集します。
シャードがインターネット接続を回復すると、その変更はサーバーに送信されます。 サーバーは Atlas の削除操作を送信します。 Device Sync の競合解決ルールに従って削除は常に優先されるため、Atlas の削除は Sarah の編集ではなく保持されます。 サーバーは Sarah の編集内容を mat のデバイスに送信しません。 データは、マトリックスとシャードのデバイス間で再度契約されます。
特別な考慮事項
カウンター
カウントに整数を使用する場合は特別なケースです。 ほとんどのプログラミング言語で増分操作（ v
+= 1など）を実装する方法は、値を読み取り、結果を増加させて保存する方法です。 これは、複数のパーティが同時にインクリメントを実行している場合は明らかに機能しません（両方で 10 を読み取り、11 にインクリメントする可能性があり、マージすると目的の 12 ではなく 11 の結果が得られます）。
この一般的なケースをサポートするために、 の値を増加させているか（または減少させた）をExpressし、マージが正しい結果に到達するための十分なヒントを提供する方法を提供します。 値全体を更新するか、より意味を伝達するように編集するかを選択して、競合の解決をより正確に制御できます。
ネストされたコレクション
ネストされたコレクションは、埋め込みオブジェクトと同様に扱われます。 つまり、特定の親オブジェクトを持つ子オブジェクトと見なされます。 親オブジェクトに対する更新は、子オブジェクトを上書きする場合でも、競合の解決では常に成功します。
ネストされたコレクションの更新は、次のように解決されます。
複数のデバイスが同じ既存のネストされたコレクションを更新する場合、Device Sync は通常の競合解決ルールを使用して両方の変更を組み込みます。
複数のデバイスが同じ親オブジェクトにネストされた新しい一意のコレクションを作成する場合、「最後の更新が選出されます」ルールが適用され、Device Sync は最後の更新で他のすべての更新を上書きします。
たとえば、Sarah と エクスポート アプリのクライアントの詳細は、親のclientプロパティにネストされた配列としてモデル化されます。 Saver- とその後、Atlas はそれぞれ、オフライン中にデバイス上の同じクライアントの新しい詳細コレクションを作成します。 デバイスが同期するときに、Device Sync は Atlas によって作成されたエントリを保持します。これは、ユーザーの更新（新しいネストされた詳細コレクションの作成）が最後に行われたためです。
その後、Sarah と mat はそれぞれ、新しく作成された詳細エントリを個別に更新します。 Device Sync は、通常の競合解決ルールに従ってこれらのアップデートをマージし、新しい項目または変更された項目を時系列でリストに挿入します。
文字列
Device Sync は string の値を全体として解釈し、文字ごとに競合をマージしません。 たとえば、string 内に文字または部分文字列が挿入または削除された場合、Device Sync はこれを string の値全体の置き換えとして扱います。
辞書
Device Sync では、辞書キーの削除は削除ではなく更新と見なされます。 その結果、「削除は常に選出されます」ルールではなく、「最後の更新が選出されます」ルールが適用されます。
たとえば、犬のパフォーマンス アプリには、各犬の詳細の任意のコレクションが含まれており、キー値として入力されます。 ユーザーがオフラインになっている間に、Sarah は犬のfavorite toyエントリ全体を削除し、その後 mat は同じ犬のお気に入りのオブジェクトをtennis ballにアップデートします。 両方がオンラインに戻ると、Device Sync は両方をfavorite toyエントリの更新と見なし、Sarah の削除後に行われたため、Atlas の更新を適用します。
カスタム競合の解決
一般的に、Device Sync の競合解決はほとんどの目的で機能するため、カスタマイズする必要はありません。 つまり、カスタム競合を解決する一般的な方法は、プロパティを string から list に変更することです。 その後、各側は更新をリストに追加し、データモデルで直接必要な競合解決ルールを適用できます。 この手法を使用して、最大、最小、最初の書込み保証、最後の書込み保証、またはその他の種類の解決を実装できます。
概要
Device Sync は、複数のオフライン ライターが同時に書き込みを行い、最終的には同じ結果に集約されるように競合解決システムを実装します。
- 競合解決システムは次の 4 つのルールに従います。
削除は常に選出されます。
最後の更新が選出されます。
リストへの挿入は、時間順に並べられます。
プライマリキーはオブジェクト ID を指定します。
カウンター、ネストされたコレクション、および文字列は、クライアント コードで注意する必要がある特別なケースです。