双方向同期の競合解決


24

接続が常に利用可能ではないことを前提として、「メイン」データベースサーバーと多くの「セカンダリ」サーバー間の双方向同期、特に競合解決をどのように管理しますか?

たとえば、iOSでCoreDataを「データベース」として使用するモバイルアプリがあり、ユーザーがインターネットに接続せずにコンテンツを編集できるようにしたいと考えています。同時に、この情報はデバイスが接続するWebサイトで入手できます。2つのDBサーバーのデータが競合している場合/その場合はどうすればよいですか?
(CoreDataをDBサーバーと呼びますが、多少異なることがわかります。)

この種の問題に対処するための一般的な戦略はありますか?これらは私が考えることができるオプションです:
1.常にクライアント側のデータを優先度の高いものとして使用します
2.サーバー側でも同じ
3.各フィールドの編集タイムスタンプをマークして最新の編集を行うことで競合を解決してください

3番目のオプションは壊滅的なデータ破損の余地を開くと確信していますが。

CAP定理がこれに関係していることは承知していますが、最終的な整合性のみが必要なので、完全に除外するわけではありませんか?

関連質問:双方向データ同期のベストプラクティスパターン。この質問に対する2番目の答えは、おそらくそれができないということです。


回答:


14

「どの変更が正しいか」を知るための通常の解決策は、ベクトルクロックです。基本的には、データを保持する各リポジトリのカウンターを追跡し、特定のクライアントのビューが他の全員の状態と接続しているピアのビューと異なる場合、変更を拒否します。

答えなければならない大きな質問は、拒否された保存をどのように解決するかです。これは通常、何らかのマージ操作を意味します。

ベクトルクロックリアルタイムのタイムスタンプを使用しないことに注意してください。リアルタイムクロックの同期に伴う問題は、少なくともデータの同期と同じくらい困難です。


1
ニースは、これは私が探していたものである
K.Steff

10

これはビザンチン将軍の問題であり、解決できません。将来のある時点で、一度に同期を実行するのに十分な信頼できる帯域幅があることを保証できない場合、2つのサーバーの同期を保証することはできません。


どのように行う[OK]を、しかし、これらの人は、同様の効果を得る:同期点開発
K.Steff

3
彼らは、将来、十分な帯域幅の信頼できる接続ができると仮定しています。
DeadMG

1

それを行うための標準的な方法はないと思います。各システムは、競合解決に独自のポリシーを使用します。

コンピューターと電話の2つのデバイスとGoogleスプレッドシートを使用してシミュレーションを行い、Googleドキュメントが競合を自動的に処理する方法を確認しました。ここにいくつかのケース:

事例1

  1. コンピューターと電話はオフラインです
  2. 値が「computer」のコンピューター編集セルおよび値が「phone」の電話編集セルの後
  3. コンピューターがオンラインになる
  4. 電話がオンラインになり、コンピューターと電話の両方に「電話」と表示されます。

事例2

  1. コンピューターと電話はオフラインです
  2. 値が「computer」のコンピューター編集セルおよび値が「phone」の電話編集セルの後
  3. 電話がオンラインになる
  4. コンピューターがオンラインになり、コンピューターと電話の両方に「コンピューター」と表示されます。

したがって、少なくともGoogle Docsサーバーは、作成されたとき(クライアントのタイムスタンプ)に関係なく、受信した最後のデータをより高い優先度として使用します。また、それらがバックグラウンドで同期するかどうかをテストしましたが、明らかに同期していないため、競合解決の結果はユーザーに対して透過的です。

一方、GITは競合を自動的に処理しませんが、代わりにリポジトリのマージ方法を変更しようとした最後のユーザーに委任します。

ユーザーがデータを視覚化して、フォアグラウンドでのみ同期しても問題ない場合は、Google Docsアプローチを選択します。そうしないと、ユーザーは、自分の電話がWiFiに自動的に接続している間に、PCで再編集した後に会議が非同期に変更されてライブになったことに驚くかもしれません。

バックグラウンド同期が必要な場合、最後に編集されたものとの競合をオーバーライドし、クライアントのタイムスタンプを使用します。クライアントのタイムスタンプを信頼でき、望ましくないマージのコストは、ユーザーに希望するバージョンの選択を要求するコストよりも小さくなります保つ。

そうでない場合は、フォアグラウンドで次のクライアントにポップアップを表示して、保持するバージョンを選択するようにユーザーに求めるか、マージを元に戻す機会を与えます。


1
ここに行くには、ケースバイケースのアプローチが適切な方法であることに同意します。ユーザーが変更をレビュー/マージしたくない場合があるため、「最良の」方法(gitアプローチ)が常に適用できるとは限らない
-K.Steff
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.