2 つの関連性はあるが別々のシステムを相互に同期するにはどうすればよいでしょうか?

Question

私の現在の開発プロジェクトには 2 つの側面があります。まず、外部ユーザーがさまざまな目的で情報を送信および更新できる公開 Web サイトがあります。この情報は、コロ機能のローカル SQL Server に保存されます。

2 番目の側面は、従業員が同じ記録を (概念的に) 管理し、ステータスの更新や承認などを提供するために使用する内部アプリケーションです。このアプリケーションは、独自のローカル SQL Server データベースを備えた企業ファイアウォール内でホストされます。

2 つのネットワークはハードウェア VPN ソリューションによって接続されており、これはまともなものですが、明らかに世界で最も高速なものではありません。

2 つのデータベースは類似しており、多くの同じテーブルを共有していますが、100% 同一ではありません。両側のテーブルの多くは、内部アプリケーションまたは外部アプリケーションに非常に固有です。

そこで質問は次のとおりです。ユーザーが情報を更新したり、公開 Web サイトで記録を送信したりする場合、そのデータを内部スタッフが管理できるように、内部アプリケーションのデータベースにどのように転送しますか?およびその逆...スタッフが行った更新をウェブサイトにプッシュするにはどうすればよいですか?

これらの更新がより「リアルタイム」で行われるほど、より良いことは言及する価値があります。即時である必要があるというわけではありませんが、適度に速ければ十分です。

これまでのところ、次のタイプのアプローチの使用を考えてきました。

1. 双方向レプリケーション
2. Web サービスは両側でコードを使用してインターフェイスし、変更が行われたときに (リアルタイムで) 変更を同期します。
3. Web サービスは両側でコードを使用してインターフェイスし、(キューイング メカニズムを使用して) 変更を非同期に同期します。

何かアドバイス？これまでにこの問題に遭遇した人はいますか?自分にとってうまくいく解決策は思いつきましたか?

Answer 1

これは非常に一般的な統合シナリオだと思います。個人的には、キューを使用した非同期メッセージング ソリューションが理想的だと思います。

レプリケーションなどのオーバーヘッドや複雑さを伴うことなく、ほぼリアルタイムの同期を実現できるはずです。

同期 Web サービスは、障害シナリオを処理するにはコードが非常に洗練されている必要があるため、理想的ではありません。一方のシステムが再起動され、もう一方のシステムが変更の公開を継続するとどうなりますか?送信側システムでタイムアウトが発生しますか?それはそれらに何をするのでしょうか？データを失う覚悟がない限り、変更通知を受信し、変更通知が他のシステムに確実に到達するように処理するために、ある種のトランザクション キュー (MSMQ など) が必要になります。どちらかのシステムがダウンした場合、変更 (メッセージとして渡される) は蓄積されるだけであり、接続が確立されるとすぐに、再起動されたサーバーがキューに入れられたすべてのメッセージを処理して追いつくため、システムの整合性の達成が非常に簡単になります。

.NET を使用している場合 (特に MSMQ を使用する場合)、これを簡単に実行できるオープン ソース ツールがいくつかあります。

1. nServiceBus ウディ・ダハン著
2. 大量輸送 ドルー・セラーズ、クリス・パターソン著

市販品もありますので、市販品をご検討の方はこちらをご覧ください。 ここ .NET のオプションのリストについては、「.NET のオプションのリスト」を参照してください。もちろん、WCF は MSMQ バインディングを使用して非同期メッセージングを実行できますが、nServiceBus や MassTransit などのツールを使用すると、要件を非常に単純なジョブにする非常に単純な送信/受信 API や Pub/Sub API が提供されます。

Java を使用している場合、Mule や ActiveMQ など、この種の双方向の非同期メッセージングを簡単に実行できるオープン ソース サービス バス実装が数多くあります。

読むことも検討してみてはいかがでしょうか ウディ・ダハンのブログを読みながら、彼のポッドキャストをいくつか聞いています。ここにあります さらに良いリソースをいくつか 始めましょう。

Answer 2

私は同様のプロジェクトの途中ですが、低速接続 (場合によってはダイヤルアップ) で同期を保つ必要があるサイトが複数ある点を除きます。

まず、変更を追跡する必要があります。SQL 2008 を使用できる場合 (2 GB の制限が問題にならない場合は、Express バージョンでも十分です)、データベースと各テーブルで変更追跡をオンにするだけで、問題が大幅に軽減されます。本社では拡張スキーマを備えた SQL Server 2008 を使用し、各サイトではデータのサブセットと制限されたスキーマを備えた SQL Express 2008 を使用しています。

次に、変更を追跡する必要があります。 同期サービス このトリックはうまく機能し、メイン データベースへの WCF ゲートウェイの使用をサポートします。この例では、 SQL Expressクライアントを使用した同期 このサンプルは出発点として使用できますが、SQL 2005 に基づいているため、2008 の変更追跡機能を利用するには更新する必要があることに注意してください。デフォルトでは、同期サービスはクライアント上で SQL CE を使用しますが、あなたの場合はこれでは十分ではないと思います。Web サーバー上で定期的に (必要に応じて 10 秒ごとに) Synchronize() メソッドを実行するサービスが必要です。これにより、ローカルで行われた変更がメイン データベースに通知され、そこで行われたすべての変更がサーバーに要求されます。get および apply SQL コードを設定してストアド プロシージャを呼び出すことができ、競合を処理するイベント ハンドラーを追加できます (例:クライアント更新とサーバー更新）を確認し、それぞれの側でそれに応じて解決します。

Answer 3

クライアントとして 1 つのショップがあり、3 つのストアが同じ VPN に接続されています
そのうちの 2 つのショップにはそのショップの「サーバー」として実行されているコンピューターがあり、3 番目のショップには「マスター データベース」があります。
すべてをマスターに同期するための最良の解決策はありませんが、うまくいきます。2 つのストアのすべてのテーブルのすべてのレコードのタイムスタンプをチェックするアプリケーションを実行する専用の PC があり、前回の同期時と異なる場合は結果をコピーします。
これは両方の方法で機能することに注意してください。つまり、マスター データベース内の製品を更新すると、この変更は他の 2 つのショップに反映されます。いずれかのショップで新しい注文があると、それは「マスター」に送信されます。
いくつかの最適化を行うと、すべてのショップを約 20 分で同期させることができます

Answer 4

最近、私は SQL Server Service Broker を使用して多くの成功を収めてきました。SQL Server Service Broker は、実装にほとんど手間をかけずに、すぐに使用できる信頼性の高い永続的な非同期メッセージングを提供します。

• セットアップは簡単で、学習を進めるにつれて、より高度な機能のいくつかを使用できるようになります。
• ほとんどの人には知られていませんが、デスクトップ エディションの一部でもあるため、ワークステーション メッセージング システムとして使用できます。
• 既存の T-SQL スキルをお持ちの場合は、メッセージの読み取りと書き込みを行うすべてのコードが SQL で実行されるため、そのスキルを活用できます。
• 目がくらむほど速いです

これは SQL Server の中であまり宣伝されていない部分ですが、一見の価値は十分にあります。

Answer 5

パブデータベースの入力テーブルのデータをプライベートデータベースの保留中のテーブルにコピーするジョブを作成するだけだと思います。次に、プライベート側でデータを更新したら、それをパブリック側にレプリケートします。パブリック側でレプリケートされたデータが更新されていない場合は、非常に簡単なトランザクション レプリケーション ソリューションとなるはずです。