1

非常に時間に敏感な Web アプリケーション (応答時間は 100 ミリ秒未満である必要があります) を実行しており、多くの要求 (ピーク時で毎分約 20 万要求) があります。アーキテクチャは非常にシンプルです。ロード バランサー、Apache と php を実行する複数の Web サーバー、MySQL を実行するデータベースです。

また、これらのリクエストに基づいて統計を生成できる必要があります。

約 1 年前、現在のトラフィック量の 10 分の 1 を処理していたとき、定期的に mysql からログをダンプし、それらを別のサーバーに転送し、再度インポートしてそこで統計を実行する bash/python スクリプトをいくつか開発しました。応答時間を短くするために、本番サーバーの処理を最小限に抑えます。

ご想像のとおり、このソリューションはうまく拡張できず、現在、統計サーバーはかろうじて追いついていません。リアルタイムで統計を生成する方法が必要です。

この種のセットアップの経験はありますか? 現時点での私たちの考えは、Web サーバーがリクエストごとにリアルタイムで統計サーバーを呼び出すようにすることです。

主な問題は次の 2 つです。

  • 応答時間が長くなりすぎないように、これにどのようにアプローチする必要がありますか
  • 統計サーバーまたはサーバーは、すべてのウェブヘッドからのすべてのリクエストを処理する必要があります。または、水平方向にスケーリングできる必要があります。
4

2 に答える 2

2

1) 別の MySQL サーバー 別の MySQL サーバーに直接接続して、そこに統計情報を書き込んでみませんか? この時点で頭の上から毎日テーブルを作成し、不要なときに古いテーブルを簡単に移動できるようにしました。ここでの問題は、水平方向のスケーラビリティの欠如ですが...

2) NoSQL このような場合、MongoDB または Redis を使用する必要がありますか? それらはメモリベースであり、シャーディングを提供するため、はるかに高速です。

3) 独立した統計サーバー HTML を提供している場合は、URL で指定されたパラメーターから統計情報を書き込むことができるリモート サーバー上のスクリプト (および JavaScript が無効になっているユーザーの URL を持つタグ内の小さな img) を呼び出すための JavaScript メソッドを追加できます。これにより、アプリケーションサーバーからすべてが完全にオフロードされ、提案#1または#2を試すことができます...

于 2012-04-18T22:18:00.693 に答える
2

データベースを使用する理由 リクエストが入ってくると、オンザフライでメモリ内の平均偏差と標準偏差を計算します。この方法では待ち時間がなく、MBean コンソールを使用して値にアクセスできます。

これは、クラスターではなく、個々のサーバーでのみ機能します。

于 2012-04-18T20:21:53.450 に答える