2

状況

ユーザーはドキュメントをアップロードできます。キューメッセージはドキュメントIDとともにキューに配置されます。ワーカーロールがこれを取得し、ドキュメントを取得します。Luceneで完全に解析します。解析が完了したら、Webrole上のLuceneIndexSearcherを更新する必要があります。

Webの役割では、静的なLucene IndexSearcherを保持しています。そうしないと、検索要求ごとに新しいIndexSearchを作成する必要があり、これにより多くのオーバーヘッドなどが発生します。

私がしたいのは、ワーカーロールからWebロールにIndexSearcherを更新する必要があるという通知を送信することです。

可能な解決策

  • ある種の通知キューを作成します。Webロールは、通知キューをチェックし続ける無限のタスクを開始します。メッセージを見つけた場合は、IndexSearchを更新する必要があります。
  • ワーカーロールでWCFサービスを開始し、Webロールに接続します。ワーカーロールからコールバックを実行し、サービスを介してWebロールにIndexSearcherを更新する必要があることを伝えます。
  • 定期的に更新するだけです

最善の解決策は何ですか、またはこれに対する他の解決策はありますか？

どうもありがとう ！

4

2 に答える 2

2

ワーカーロールがのようなPKを使用して、完了した各ジョブの詳細をテーブルに書き込む場合、(DateTime.MaxValue - DateTime.UtcNow).Ticks.ToString("d19")処理された最新のジョブのソートされたリストがあります。次のようにテーブルをポーリングするようにWebロールを設定します。

var q = ctx.CreateQuery<LatestJobs>("jobstable")
    .Where(j => j.PartitionKey.CompareTo(LastIndexTime.GetReverseTicks()) < 0)
    .Take(1)
    .AsTableServiceQuery()

if (q.Count() > 0)
{
    //new jobs exist since last check... re-index.
}

インデックス作成作業を行うワーカーロールの場合、競合を心配することなくテーブルに無差別に書き込むことができるため、これは優れています。あなたのために、あなたは彼らが処理している仕事の監査ログも持っています（あなたがそこにいくつかの詳細を入れていると仮定して）。

ただし、残りの問題が1つあります。インデックスを更新するWebロールが1つあるようです。もちろん、この1つのWebロールは、選択した頻度でこのテーブルをポーリングできます（後で検索するためにLastIndexTimeを追跡するだけです）。問題は、複数ある場合にWebロールの同時実行性を制御する方法です。各Webロールは独自のインデックスを維持していますか、それともすべての場所にインデックスを保存していますか？申し訳ありませんが、それが明らかな場合、私はLuceneの専門家ではありません。

とにかく、WebRoleに複数のインスタンスがあり、すべてが表示できる単一のインデックスがある場合は、複数のロールがインデックスを何度も更新しないようにする必要があります。これは、インデックスをリースすることで実行できます（blobストレージに格納されている場合）。

コメントに基づいて更新：

各WebRoleインスタンスに独自のインデックスがある場合は、リースについて心配する必要はありません。これは、BLOBリソースを一緒に共有している場合のみです。したがって、この手法はそのままで正常に機能するはずです。唯一の潜在的な障害は、Webロールのポーリング間隔がわずかに同期しておらず、すべての更新まで（ヒットしたインスタンスに応じて）結果が多少異なる可能性があることです。テーブルで30秒ごとにポーリングすると、最大で同期がとれなくなります。各Webロールインスタンスは、最後に更新された時刻を追跡し、その時点から増分検索を実行する必要があります。

于 2011-08-30T14:04:37.117 に答える
1

アップロードの頻度によっては、不要な更新を引き起こすキューメッセージが見つかる場合があります。たとえば、12個のアップロードを取得し、それらを近接して処理すると、それぞれがWebロールに更新するように指示する12個のキューメッセージが作成されます。単一のシグナル（おそらくテーブル行またはSQL Azure行）を保持する方が理にかなっています。行の値を1に設定するだけで、更新の必要性を示すことができます。Webロールがこの変更を検出したら、0にリセットして更新を開始します。注：Azureテーブルの行を使用する場合は、更新をポーリングする必要があります（トラフィックによっては、多数のトランザクションの蓄積を開始する可能性があります）。この信号にもAppFabricキャッシュを使用できます。

Webロールの内部エンドポイントでWCFサービスを使用できます。ただし、まだバーストの問題があります（たとえば、Webロールの更新中に12個のアップロードを取得した場合、さらに12個の更新を実行する必要はありません）。

于 2011-08-30T11:26:26.143 に答える