3

現在進行中のプロジェクトは新しい MVC Web サイトで、主に WCF サービスを使用して、Web サービスを介してサード パーティの請求システムにアクセスし、ユーザーのパーソナライズ用に小さな SQL データベースを使用します。WCF サービスは、SQL データベースに nHibernate を使用します。

ロード バランシング、フェイルオーバー、およびメンテナンスのために、ある種の Web ファームを実装したいと考えています。複数の WCF サービスが実行されている場合に、nHibernate のキャッシュとデータベースの同時実行を処理する最善の方法を決定しようとしています。

私が考えていたいくつかのシナリオ...

1) 複数の IIS サーバー、1 つの WCF サーバー。このセットアップでは、WCF サーバーが単一障害点になりますが、nHibernate キャッシュまたはデータベースの同時実行性には問題はありません。

2) それぞれ独自の WCF サービスを備えた複数の IIS サーバー。これにより、単一障害点が取り除かれますが、あるマシンの nHibernate は、別のマシンによって行われたデータベースの変更を認識できなくなります。

番号 2 に対するいくつかの解決策は、IStatelessSession を使用することです。これにより、キャッシングを行わず、nHibernate が常にデータベースから直接フェッチします。パーソナライゼーション データベースにはほとんどオブジェクトが含まれていないため、これが最も実現可能性があります。memcached や Velocity などの第 2 レベルのキャッシュも検討していますが、このシステムではやり過ぎかもしれません。

この種のアーキテクチャを実行した経験があるかどうかを確認し、解決策のアイデアを得るために、これを公開しています。ありがとう！

4

2 に答える 2

2

ここで何か不足していますか? Web サーバー上の nhibernate に問題はありません。各 nhibernate ボックスは、データストアから入力される独自のキャッシュを保持するため、アプリケーション キャッシュは問題になりません。キャッシュの更新を行う理由を監視できるテーブルの作成を検討してください。以前は、.net 2.0 の CacheDependency クラスを使用してこれを行っていました。これは、列への変更を検出し、関連するアイテムをキャッシュから削除します。そのため、ユーザーが新しい製品を挿入すると、キャッシュが削除され、製品を取得するための次の呼び出しでキャッシュが再度読み込まれます。古いですが、コンセプトについてはhttp://msdn.microsoft.com/en-us/magazine/cc163955.aspx#S2をご覧ください。乾杯

于 2010-02-10T09:41:06.623 に答える
2

キャッシングをしないことが問題になるまで、キャッシングをしないことをお勧めします。DB は独自のキャッシングを行い、同じデータを繰り返し検索する手間を省きます。そのため、心配しなければならないのは、ネットワーク上のデータだけです。あなたの説明から判断すると、そこで問題が発生することはありません。そのような段階に達した場合は、分散キャッシュを使用してください。サーバーが個別にキャッシュできるようにすると、更新時にデータがバウンスする問題が発生します。

于 2010-02-17T00:02:01.623 に答える