アイテムに ID の GUID がある複数のデータベースを同期しようとしています。つまり、1 つのアイテムがすべてのデータベースで同じ ID を持っています。
私の質問は次のとおりです。あるデータベースのアイテムを変更または作成し、この変更を他のデータベースに同期したい場合、次のことを行う必要があります。
1.) アイテムが新しいか変更されたばかりかを確認します。新しい場合は save() 関数を使用し、変更された場合は update() 関数を使用します。
また
2.) 新規か変更済みかを確認せず、単に saveOrUpdate() 関数を使用しますか?
コメントでユースケースを見た後、最終更新/最終同期時刻がいつだったかを（クライアントとサーバーの両方で）追跡するのが最善の方法だと思います。最終同期時間が null の場合、または最終更新時間より前の場合は、データを同期する必要があることがわかります。
さて、あなたの質問の核心である同期方法に進みましょう。クライアントは、オブジェクトを送信するときにサーバーの状態を知る必要はありません。実際、そうすべきではありません。クライアントがオブジェクトを投稿し、サーバーがそれを受信して処理するが、クライアントが応答を受信する前に接続が切断される場合を考えてみましょう。これは非常に有効なシナリオであり、データの不一致が発生します。その結果、サーバーが (クライアントから) オブジェクトを受信したかどうかを判断しようとすると、最終的に悪い状態になる可能性があります。
最善の解決策は、サーバー上にべき等エンドポイントを作成することです (アップサート メソッド、またはsaveOrUpdate質問で参照したように)。これにより、オブジェクトの処理方法を決定できます。サーバーは、主キーでデータベースにクエリを実行して、オブジェクトがあるかどうかを判断できます。ある場合は更新でき、ない場合は挿入できます。
当然のことながら、データだけでなくパフォーマンスも重要です。ただし、データベースの主キーに固執し、追加する 1 つの選択クエリは非常に最小限 (10 ミリ秒未満) にする必要があります。パフォーマンスをさらに絞り出したい場合は、常に memcache または redis をキャッシュ レイヤーとして使用して、データベースに特定の GUID があるかどうかを判断できます。このように、オブジェクトが存在するかどうかを判断するために、(データベースではなく) メモリにアクセスするだけで済みます。そのオーバーヘッドは、Web サーバーとキャッシュ サーバー間のレイテンシでのみ測定されます (メモリの読み取りは非常に安価であるため)。
tl;dr
Upsert (またはsaveOrUpdate) が最適です。あるマシンの状態を別のマシンで追跡しないようにしてください。