メッセージキューにデータベースを使用したASP.NETチャットアプリケーション
-
19-09-2019 - |
質問
メッセージを交換するためにSQLServerデータベースを使用するチャットWebアプリケーションを開発しました。
すべてのクライアントは、X秒ごとに投票して、新しいメッセージを確認します。
このアプローチが多くのリソースを消費していることは明らかであり、それを行う「より安い」方法があるかどうか疑問に思っていました。
「存在」に同じアプローチを使用します。誰がオンになっているかを確認します。
解決
リアルタイムチャットアプリのようなものについては、SQLバッキングを備えた分散キャッシュをお勧めします。私はたまたまenyim .NETプロバイダーとMemcachedが好きなので、次のようなことをします。
- ユーザー投稿メッセージ
- システムはデータベースにメッセージを書き込みます
- システムはキャッシュにメッセージを書き込みます
- すべてのユーザーは、新しいメッセージのために定期的にキャッシュを投票します
データベースバッキングにより、キャッシュがクリアされた場合、またはアプリケーションが再起動された場合にキャッシュをプリロードできますが、機能ビットはデータベースを投票するのではなく、メモリ内キャッシュに依存します。
他のヒント
フラッシュやJavaアプレットなどのブラウザプラグイン/拡張機能を使用しないと、ブラウザは基本的に一方向のコミュニケーションツールです。データを取得するには、ブラウザがリクエストを開始する必要があります。データをブラウザに「プッシュ」することはできません。
Ajax Polling Methodを使用してサーバー「プッシュ」をシミュレートする多くのWebアプリ。トリックは、頻度/データサイズと帯域幅およびサーバーのリソースのバランスをとることです。
Gmailの簡単な観察をしました。 5秒ごとにhttppostポーリングを行います。 「状態」の変更がない場合、応答データサイズはわずか数バイトです(HTTPヘッダーは含まれません)。もちろん、Googleには膨大なサーバーリソースと帯域幅があります。だから私は言及しています:良いバランスを見つけることです。
それは「ユーザーエクスペリエンスとサーバーリソースの改善」です。 X秒ごとに簡単な投票ではなく、創造的な投票戦略の方法を発表する必要があるかもしれません。
たとえば、党Aからのアクティビティがない場合、3秒ごとに投票してください。パーティーAがタイピングしている間、5秒ごとに投票してください。これは単なるIllustratonです。数字で遊んだり、より効率的なものを出したりすることができます。
最後に、データ交換。課題は、同じ情報を伝えるために最小データサイズを渡す方法を見つけることです。
私の2セント:)
SQL Server 2005を使用している場合は、通知サービスを確認できます。 SQL 2008で通知サービスが削除されたため、SQL Serverがデータベースの変更のクライアントアプリケーションに通知できるように設計されたため、これがSQL 2005にロックされます。
もう少しスケーラブルなものが必要な場合は、ユーザーのレコードにいくつかのビットフラグを置くことができます。ユーザーのメッセージが入っているとき、新しいメッセージのビットをtrueに変更します。メッセージを読んだとき、メッセージを0に変更します。そうすれば、すでにキャッシュをしている可能性が非常に高い非常に小さなフィールドを読んでいます。
ワークフローの準備ができていますか。 1の場合は、メッセージテーブルからメッセージを取得します。 0の場合は何もしません。
ASP.NET 4.0では、できます JavaScriptオブジェクトと配列でオブザーバーパターンを使用します IE:ajax jsonはjqueryまたはpagemethodsで電話をかけます。
返品するデータがあるかどうかについて分析を行うには、常にデータベースを押す必要があります。トリックは、これらの呼び出しを小さくし、必要な場合にのみデータを返すことです。
SQL Server 2005に組み込まれた2つの関連ソリューションがあり、SQL Server 2008でまだ利用可能です。
1) サービスブローカー, 、サブスクライバーがキューに読み取りを投稿することができます(wait ..を受信コマンド..)。あなたの場合、これらのキューをフロントするサービスブローカーサービスを使用して、データベースからメッセージを送信することをお勧めします。投票はありません。待機中のクライアントは、メッセージが受信されるとアクティブ化されます。
2) クエリ通知, 、サブスクライバーがクエリを定義することを可能にし、そのクエリを実行したことから生じるデータセットが変更される場合に通知を受信します。サービスブローカーに基づいて構築されたクエリ通知は、やや使いやすくなりますが、効率が低下する可能性もあります。 (クエリ通知とその兄弟ではなく、イベント通知はしばしば通知サービス(NS)と間違えられます。これは、2008年にNSが廃止されるため懸念を引き起こしますが、クエリとイベントの通知はまだ完全に利用可能であり、SQL Server 2008でさらに強化されています)。