変更ログとしてMongoDBを使用する2つのシステム間の同期
2つの関連システムを開発しています。そのうちの1つ（A）は、お客様のマシンにインストールされます。残りの（B）は私の組織で使用されます。
各システムには独自のデータベース（リレーショナル）があり、それらのスキーマは異なります。ただし、両方のシステムを同期する必要があります。さらに、Bの一部の変更をすべてのクラスAシステムにエクスポートし、その他の変更を特定のシステムにのみエクスポートする必要があります。
一部の顧客はインターネットに接続していないため、ファイルの交換を介して同期を行う必要がある場合があります。
そのため、次のようにこの問題を解決する予定です。
- 各システムは、そのデータベースの変更ログを維持します。 MongoDBで実装する予定です。
- システムが同期プロセスを初期化すると、ログから行われたすべての変更が取得されます。システムがBの場合、取得される変更は宛先によって異なります。次に、システムはそれらをXML形式でシリアル化し、最後に（ファイルまたはネットワーク経由で）送信します。
- 他のエンドポイントが変更セットを受信すると、それらのシリアル化を解除します。次に、システムはデータに対していくつかの変換を行います。これは必要な場合があり、最後に変更を記録します。このステップでは、必要に応じて、システムは存在する可能性のある競合を解決する必要があります。
- 最後に、受信側システムはその変更（および競合解決の他の製品）を送信します。
このアプローチは実現可能で、スケーラブルでエレガントですか？どのような変更または追加を行いますか？
まだ行っていない場合は、イベント駆動型システム、イベントソーシング、結果整合性について読むのが興味深いかもしれません。あなたが説明しているシステムには、これらのパターンと多くの類似点があります。これは良いことです。
あなたのアプローチは、特に良さそうです：
- 順序付けされた変更ログを使用すると、同期プロセスは、最後に確認された変更以降に行われた変更のみを取得できます。これにより、処理時間が短縮され、スケーラビリティが向上し、インターネット接続が利用可能な場合に、ほぼリアルタイムの同期を構築できます。
- インターネットに接続していない顧客は、高速同期に頼って誤ってスケーラビリティの問題が発生するのではなく、遅延および順序が乱れた同期に対処することを考える必要があります。
ドメインモデルの詳細がわからない場合、私の問題は、競合の解決が最も問題を引き起こす部分だと思います。それぞれの種類の紛争がどのように解決されるかについて、私は少し時間をかけて考えました。特に：
- 一部の競合ではユーザーの解決が必要ですか？
- 顧客システムは常に競合を解決するための適切な場所になりますか？
- お客様のシステムが変更を送信する場合、手順4の後にシステムBで競合が発生する可能性はありますか？
各システムは、そのデータベースの変更ログを維持します。 MongoDBで実装する予定です。
eventstore を使用できます。データを更新すると、ストアに新しいイベントが作成されます。
システムが同期プロセスを初期化するとき、ログから行われたすべての変更を取得します。システムがBの場合、取得される変更は宛先によって異なります。次に、システムはそれらをXML形式でシリアル化し、最後に（ファイルまたはネットワーク経由で）送信します。
任意のメカニズムを使用してイベントを送信できますが、可能であれば、ファイルを処理する必要がないバスを使用する方が簡単です。通常、これらは、接続が送信できるようになるまでメッセージを保持するように構成できます。
他のエンドポイントが変更セットを受信すると、それらのシリアル化を解除します。次に、システムはデータに対していくつかの変換を行います。これは必要な場合があり、最後に変更を記録します。このステップでは、必要に応じて、システムは存在する可能性のある競合を解決する必要があります。
イベントをドメインオブジェクトに適用するだけです。
最後に、受信側システムはその変更（および競合解決の他の製品）を送信します。
同じアプローチを使用します。