プーリング機構を用いた双方向ファイル同期

Dropbox、Microsoft OneDrive、Microsoft SharePointなどのファイル管理のための様々なシステムを同期させることに興味がありますか？ファイルとドキュメントの双方向同期の基本原理、ベストプラクティス、開発時間の短縮方法、そしてもちろん金銭的なコストを削減する方法を紹介します。

最初から同期させたい各システムのAPI(Application Program Interfaces)を扱う必要があります。認証に対応するためには、スキーマの表現や原理、データ操作を学び、共通の言語にする必要があります。これは、開発者が何百ものドキュメントページを学習するハードワークか、統合プラットフォームを使用して達成することができます。

偶然にも、私たちは非常にユニークな技術を持つ統合プラットフォームを提供しています。 Connect Bridge.このソフトウェアを使用すると、簡単なSQL(Standard Query Language)を使用して、様々なシステムのAPIを利用することができます。また、.NET、Java、その他の言語の開発者であっても問題ありません。スキーマはConnect BridgeのQuery Analyzerツールで可視化され、開発者はこのツールで彼のクエリをテストし、すぐに結果を見ることができます。その後、あなただけの変更を追跡するためにデータベースを制御する必要があり、あなたは行っても良いです。

プーリング機構の原理は非常に単純で、ターゲットシステムからのデータは、指定された時間帯またはユーザーのアクションに応じて一度だけ取得され、処理されます。そして、それだけです。

すべてのシステムがリアルタイムでファイル変更後にアクションをトリガーする機能を提供しているわけではありません。それらのいずれかがこの機能を提供していない場合、それは深刻な合併症を引き起こす可能性があります。だから主な利点は、ファイル同期のデータと時間の制御です。それはあなたに何が起こっているかの大きな絵を与え、不必要なアクションを避けるために可能性を開きます。

1つのプール間の時間が長くなるほど、ファイル間の競合が発生する可能性が高くなります。

双方向同期では、システムがお互いに修正を行っているときに、異なるシステムで同じファイルが同時に修正されることが起こるかもしれません。しかし、その場合はどうなるのでしょうか？どちらが正しいバージョンなのでしょうか？この場合、どのバージョンを上書きするかを決めるために、どのシステムがマスターでどのシステムがスレーブかを指定する必要があります。

変更を追跡するためには、同期化されたターゲットシステムのマッピングされたアイテムを持つデータベースを持つ必要があります。更新の認識は、変更時間やバージョン、あるいはターゲットシステムが提供する使用可能なものであれば何でも構いません。アイテムのレコードがデータベースに存在しない場合は新規作成、ターゲットシステムには存在しないがデータベースにレコードがある場合はターゲットシステムで削除されています。以上です。システムによっては、指定した期間に変更を求めることができるものもありますが、いずれにしても、ターゲットシステムや接続による障害のために何が同期されたかを追跡する必要があります。

メインの同期ロジックがターゲットシステムで動作するようにするためには、それぞれのプロバイダクラスを作成して、基本的なCRUD(Create-Read-Update-Delete)操作を指定する共通インターフェースを実装するのが良いでしょう。そうすれば、コアアルゴリズムでは、どれがどれであるかを気にする必要はありません。双方向同期の一般的なロジックを作成するだけで、プロバイダクラスが操作自体を処理してくれます。良いコアアルゴリズムが実装されていれば、同期しているシステムの数は関係ありません。他のプロバイダの実装を追加すればいいだけです。このアルゴリズムは、競合を正しく処理するために、マスターとスレーブの階層に従う必要があります。競合を正しく処理するためには、マスターとスレーブの階層に従う必要があります。

作成や変更の操作にはあまり影響を与えることはできませんが、最も重要なのはデータの取得です。全てのデータを取得する必要はありません。最後のファイル同期時間を保持しておき、作成・変更時間が新しいものだけをサーバに依頼することができます。削除操作はサーバのロジックに依存します。中には一括削除操作を提供しているものもあります。また、フォルダ全体を削除した場合に、削除した項目の中のサブ項目を全て削除してしまうと、一つ一つ削除しても意味がありません。

まず第一に、コードの異なる場所からデータを取得することは、ファイルのアップロードのような長期的な操作の間に分割してしまうと、ユーザーがシステムの内容を変更することができ、同じプログラムのコンテキストで異なるデータを扱うことになり、深刻なトラブルを引き起こし、データ損失につながる可能性があるため、良いアイデアではありません。

処理の途中で、対象システムの内部サーバエラーや接続切れなど、自分ではどうすることもできない様々な例外が発生する可能性があります。ベストプラクティスは、例外処理を、すべての操作が完了するまで実行しようとするが、次のユニットに進まないコードをカバーする個別のユニットに分割することです。これはレベルツリーのようなものです。例えば、最初のシステムで作成された5つのフォルダに10個のファイルがあることを同期が発見したとします。そこで、他のシステムでこれらの5つのフォルダの作成を開始しますが、挿入操作の1つが例外をスローします。他の4つのフォルダの作成を試みることができますが、2つのファイルのパスが存在しないため、ファイルの挿入を開始すべきではありません。それは別の、より複雑な方法で処理することができますが、私はそれをできるだけシンプルに保つために信頼しています。より多くのシステムの双方向同期化における可能性のあるエラーシナリオのバリエーション数は非常に多く、さらに再帰的です。