Windows Azure で、1 日に開始されたゲームの数を追跡するグローバル カウンターをセットアップしようとしています。プレーヤーがゲームを開始するたびに、クライアントからサーバーへの Web サービス呼び出しが行われ、グローバル カウンターが 1 つ増分されます。これは、データベースで行うのはかなり簡単なはずです...しかし、どうすればこれを効率的に行うことができるのでしょうか。データベース アプローチは、同時に数百のクライアントに適していますが、クライアントが 100,000 の場合はどうなりますか?
あなたの助け/アイデアをありがとう！
1 年ちょっと前に、これはクラウド カバー エピソードのトピックでした:クラウド カバー エピソード 43 - Windows Azure によるスケーラブル カウンター。彼らは、Apaythy ボタン(Facebook の Like ボタンに似ています) を作成する方法について話し合いました。
Steve Marx は、ソース コードを含むブログ投稿でこれについても詳しく説明しています: Architecting Scalable Counters with Windows Azure . このソリューションでは、次のことを行っています。
Interlock.Incrementローカルカウンターの変更に使用まあ、たくさんの選択肢があります。そして、どれがあなたに最適かわかりません。ただし、ここではいくつかの長所と短所を紹介します。要件があれば、独自の結論に達することができます。
最も簡単な答えは、「保管しておいてください」です。SQL Azure とコア Azure テーブルまたはブログ ストレージ オプションの両方が用意されています。取り組むべき問題の 1 つは、大規模な同時実行に直面した場合のパフォーマンスですが、正確性についても考えることをお勧めします。この問題 IMO を外部委託するために、アトミック インクリメントをサポートするものが本当に必要です。
ストレージ指向のオプションのもう 1 つのバリエーションは、高可用性 VM です。Azure で独自の VM をスピンアップし、データ ドライブを Azure ドライブに戻し、OS 上で何かを使用してこれを行うことができます (データベース サーバー、ファイル システムを直接使用するアプリなど)。これは自宅で行うことに似ていますが、かなり残念なトレードオフがあります...クラウド全体がこの 1 つの VM の可用性に依存するようになり、コスト、ソリューションのスケーラビリティ、等々。VM を見る場合は、Splunk も考慮すべきオプションです。
以前のコメンターが述べたように、ログ データから計算できます。しかし、これはおそらく超リアルタイムではありません。
サービス バスは、検討すべきもう 1 つのオプションです。これらのイベントのメッセージを SB 経由でポンプし、それらを読み取って「概要」を発行するコンシューマーを用意できます。これを見ると、考慮すべき設計パターンがたくさんあります。SB スタックはかなりよく文書化されています。SB のもう 1 つの興味深い要素は、100% の正確性とパフォーマンス/スケール/コストをトレードオフできる可能性があることです。これは、目標によっては、価値のあるトレードオフになる可能性があります。
Azure は、適合する可能性のあるキューも公開します。おそらくSBの方が適していると思いますが、この道を進む場合は両方を見る価値があります.
申し訳ありませんが、特効薬はありませんが、これがお役に立てば幸いです。
.NET Multi-Tier Applicationで説明されているパターンに従うことをお勧めします。これにより、クライアントに対応する Web ロールと、Service Bus を使用してデータを永続化メディア (SQL Server / Azure Storage) に格納する Worker ロールを切り離すことができます。
また、これは、Web ロールまたは worker ロール、またはその両方の新しいインスタンスにまたがることができるため、スケーリングするのに効率的なモデルです。負荷に応じてダッシュボードの場合は、データを定期的にキャッシュし、キャッシュからサーバー化できます。これにより、データの精度が低下しますが、簡単にスケーリングするためのオプションが提供されます。キャッシュを 1 分ごとに無効化し、永続化メディアからキャッシュをロードして最新の値を取得することもできます。
SQL Server または Azure ストレージの使用に関しては、リレーショナル機能JOINSなどの必要がない場合は、Azure ストレージを使用することができます。