2 つのプロセス (クライアントとサーバーなど) 間でネットワーク経由でリアルタイムにデータを同期するにはどうすればよいでしょうか?
サーバー上に構築されたさまざまなドキュメント/データセットがあり、クライアントによってダウンロードおよび表示されます。ダウンロードが完了すると、ドキュメントは最新の状態を保つために継続的に更新されます。
これは単純で一般的な概念のようですが、このレベルの抽象化を提供するツールは見つかりません。何を探しているのかさえわかりません。しっかりとしたツールをサポートする同様のコンセプトがあるのではないでしょうか? おそらく、まとめなければならないさまざまなツールのチェーンがあるのではないでしょうか? これまでに私が検討したことは次のとおりです。
- すべての変更を 1 回のホップ (0.5 RTT) で伝播する必要があり、これにより、ポーリング (通常は 10 RTT を超える) とキャッシュ無効化手法 (1.5 RTT) が除外されます。
- データが多すぎて変更が多すぎるため、データ複製と単純な通知ブロードキャストはオプションではありません。クライアントは、特定のドキュメントを選択してダウンロードし、変更を監視できる必要があります。
- 私は現在、仕事をするメッセージパッシングパターンを使用していますが、絶望的に非生産的です. あまりにも低いレベルの抽象化で機能します。これは手間がかかり、エラーが発生しやすく、アプリケーションの複雑さが増してもうまく拡張できません。
- HTTP やその他の RPC に似た手法は、最初のフェッチには適していますが、後続の同期にはポーリングが必要になります。リバース リクエスト (データ ソースからデータ コンシューマーへ) を実行する場合、変更通知は可能ですが、メッセージ パッシングよりもさらに複雑です。
- RPC (初期フェッチ用) とメッセージ パッシング (更新用) を組み合わせることは、2 つのパラダイム間のインピーダンスの不一致だけでなく、2 つの並列接続を介した通信の調整に伴う複雑さのため、悪夢であることが判明しました。統一されたものが必要です。
- WebSocket と Comet は、変更通知を実装するための一般的な方法ですが、生産性を高めるには追加のライブラリが必要であり、自分のアプリケーションに適したライブラリを知りません。
- メッセージ キューは、基本的なメッセージ パッシング パターンを維持しながら、ネットワーク上に仲介者を置くだけです。カスタム メッセージ フィルター/ルーターを使用すると、ライブ ドキュメントの概念に近づくことができますが、MQ の上にカスタム ミドルウェア レイヤーを実装しているように感じます。
追加の要件が山ほどあります (両端でのネイティブの監視可能なデータ構造 API、インクリメンタル アップデート、カスタム メッセージ フィルター、カスタム接続ルーティング、クロスプラットフォーム、堅牢性とスケーラビリティ)。しかし、それらの要件を検討する前に、少なくとも私が必要とすることをしようとします。私は標準的な理由で社内フレームワークを避けようとしています - コスト、市場投入までの時間、長期的なメンテナンス、そして開発者を満足させ続けるためです。