ホームページ  >  記事  >  バックエンド開発  >  PHP で高い同時実行性をサポートする Web サイトを作成するには何をする必要がありますか?

PHP で高い同時実行性をサポートする Web サイトを作成するには何をする必要がありますか?

WBOY
WBOYオリジナル
2016-06-17 08:30:371144ブラウズ

しかし、同時実行性が高く更新が速い Weibo のようなものを静的にするのは困難です。このような需要にはどう対処すればよいでしょうか。

返信内容:

一般に、高い WEB 同時実行性の問題を解決する効果的な方法は、線形スケーラブルな多層分散アーキテクチャを使用することです。
私の運用プロジェクトのアーキテクチャは次のようなものなので、ここでいくつかのアイデアを紹介します。
  1. Web サーバー (Nginx): このレイヤーは、インテリジェントな DNS 解決と組み合わせて簡単に分散および展開でき、LVS と組み合わせることで、単一障害点を簡単に防止し、リージョン アクセスの高速化を実現できます。負荷分散を実現します。この層は主に、静的リクエストの処理と、静的リソース アドレス (misc.xxxx.com) は個別に展開することも、商用クラウド ストレージ サービス (中国では Qiniu が適しており、海外では Amazon S3 が適しています)
  2. PHP 処理ノード: ノード実際には、特定のポートをリッスンするシステムプロセスであり、Webサーバーのリクエストはロードバランサー(私はAWSのロードバランサーを使用しています)を通じて分散され、分散と負荷分散を簡単に実現できます。私は今でも PHP に付属の php-fpm を使用していますが、Facebook が作成した hhvm は非常に強力ですが、hhvm が成熟したら、スムーズに置き換えることができます。 🎜>
  3. キャッシュ: Memcached が使用されます。この層の主な機能は、データベース IO を削減し、ホット データ アクセスを高速化することです。そのため、詳細については説明しません。 1 つはプログラム内でキャッシュを追加する方法で、コード結合率は低いですが、プロジェクトによっては適さない場合があります。特定のデータアクセスポイントにキャッシュを追加するこの方法は、プログラム結合度が高くなりますが、キャッシュヒット率が非常に高く、無効なキャッシュがほとんどありません。
  4. データベース: 現在のプロジェクトのデータ規模は大きくなく、当面は 1 つのデータベースのみを使用しますが、プログラム ロジックはデータベースの線形拡張に対応する準備ができています。実際、データベース層の拡張は一般的な方法で、サブデータベースとサブテーブルを作成する必要があります。これには、360 の Atlas や Alibaba のようなミドルウェアを使用することも必要です。 cobar、Taobao の TDDL およびミドルウェアは、大規模なコード変更なしで拡張できますが、特定の使用シナリオは依然として制限されており、特定のプロジェクトを個別に検討する必要があります。
  5. その他: プロジェクトによっては、アーキテクチャでキューを選択的に使用することもできます。私は現在 Beantalkd を使用していますが、Redis も良い選択です。キューの一般的な使用環境は電子メールの送信とサイト内メッセージのプッシュですが、一部のシナリオではコア データベースのバッファとしても使用でき、これは大規模な同時実行や突然のトラフィックに対処する場合にも適しています
  6. 一般に、LVS+PHP クラスター (1,000 マシン) を使用すると、1 日あたり平均 80 億のリクエストがあり、1 秒あたり 100,000 の同時リクエストがあったとしても、各マシンに割り当てられるリクエストは 100 件のみです。 PHP プログラムがよほど悪くない限り、100QPS は問題ありませんね。
  7. 本当のボトルネックはデータベースとストレージ システムにあり、データの一貫性、スケーラビリティ、可用性を保証するのは困難です。したがって、特定のビジネスシナリオに応じて、水平および垂直のサブデータベースとテーブルを実行する必要があります。

memcache クラスター キャッシュ、キーと値の高性能ストレージ、および非同期キュー タスク システムによって補完され、アーキテクチャ全体を確立できます。

WebIM などの実際の高同時実行性のタイプもあります。大規模なリアルタイム通信では、マシンは何十万もの TCP クライアント接続に耐える必要があります。この種の機能は、PHP の非同期高同時実行性 Swoole を使用して拡張できます。リンク: Swoole: PHP の非同期、並列、分散拡張フレームワーク

10 億レベルの Web システムの構築 - 単一マシンから分散クラスターまで
[質問] Xu Hanbin: 10 億レベルの Web システムの構築 - 単一マシンから分散クラスターまで - CSDN.NET この問題は本一冊分になるかもしれません。
PHP Web サイトのボトルネックは基本的にデータベースです。 一般的に中小規模のプロジェクトではハードウェアの方が人件費より安く、上司が精算してくれる。マスターとスレーブの同期は言うまでもなく、リアルタイム パフォーマンスが低いシナリオしか解決できません。たとえば、12306では、ユーザーAが最初のDBに注文を出しましたが、まだDB100番には送信されていません。この時点で、DB100番はすでにユーザーBからの注文を受け付けています。
それでは、データベース接続の数を減らします。100 人のユーザーが同じコンテンツを読む場合、1 回読むだけで済みます。したがってキャッシュがあります。
キャッシュにも問題があります。たとえば、キャッシュの内容とデータベースの一貫性を確保するにはどうすればよいでしょうか?

それでは、上記の問題については、後で会ったときに話し合いましょう。 以前は読書を減らすことについて話しましたが、今回は書くことを減らし、書く頻度を減らすことについて話したいと思います。 たとえば、Weibo 上の友人のグループにメッセージを送信する場合、その多くはオンラインではありませんが、オンライン ユーザーのメッセージを Redis に保存しても、データはすぐには更新されません。

お金があればDBサーバーを追加できますか? とにかくサーバーは安いです?各サーバーにはデータの一部が保存されており、偶数番号の投稿はサーバー A から取得でき、奇数番号の投稿はサーバー B から取得できます。 何?投稿を時間順に並べ替えるにはどうすればよいですか?クリック数で並べ替えるとどうなるでしょうか? クリックを保存するための新しい DB サーバーを構築し、ID を投稿することはすべて簡単に行うことができます。 面倒なニーズがある場合は、検索チームにサポートを依頼してください。適時性が高くなくても、対応は簡単です。さらに、トラフィック量が多いキャッシュについては、いくつのキャッシュを設定する必要があるかにも注目してください。

N 件のコメントがありますが、クリックするとリストが空になりますか?これらの機能が 99% 使用できる限り、ICP にも問題が発生する可能性があります。ユーザーが 1 回クリックしても応答がない場合は、もう一度クリックしてください。

写真。ファイルは小さいため、Linux i ノードには制限があります。 すべてのイメージをいくつかの大きなファイルに保存し、それらを読み取るサービスを構築します。

音楽、ビデオ サービス。

違法なテキスト、音楽著作権、短いビデオ、徐々に頭が痛くなってきます。 宜山 一枚ずつ剥がしてみると、以下のような注意が必要な部分があります。
1. リソース。静的に実装できる場合は、クラウド ストレージなどの静的リソースにも分散ストレージを使用する必要があります。
2. 効率。 PHP コードでは、メモリ使用量に注意を払うようにしてください。単一スクリプトの実行効率は問題ありません。
3. キャッシュ。非永続ストレージには memcache を使用し、永続ストレージには no-sql を使用します。
4.サーバー。 nginx+fpm または nginx+apache を使用して、動的および静的に分離されたアクセスを実現します。
5.mysql。最終リポジトリといくつかの避けられないリアルタイム呼び出しライブラリとして、マスター/スレーブ処理、マスター + 複数のスレーブ、および複数の読み取り専用コピーがリアルタイム呼び出しライブラリの実装に使用されます。
6.ロードします。 Web サーバーのポーリングを実装するには、負荷分散のレイヤーをセットアップすることをお勧めします。たとえば、クラウド プラットフォームの LBS。 「10億PV級」のWebサイトが世界中にどれだけあるのか、私にはまったくわかりません。
何億もの PV を持つ Web サイトでは、このような質問はもう絶対に行われません。 静的にできるもの
静的にできないものは分散アルゴリズムを使用します


特に複雑なアルゴリズムでは、操作をデータベースに渡さないことが最善です

静的にすると、データベースへの負担が軽減されます
PHP は、apache/nginx/memcache/redis/mysql/httpds とその他のツールを組み合わせた言語ツールであり、特定のビジネス ニーズに基づいてさまざまなシステム アーキテクチャ モデルを選択します。高い同時実行性により、システム アーキテクチャが実際にテストされます
1。書き込み層
データの読み取りと書き込みに関する高度な同時実行テストは、特定のビジネス ニーズに基づいたシステム アーキテクチャです。どのデータがリアルタイムの読み取りと書き込みに対応する必要があるか、どのデータが非同期読み取りと書き込みが可能かを判断します。データの読み取りおよび書き込みモデルを明確に分析した後、データ ストレージ ソリューションを設計する必要があります。Mysql はリレーショナル データとデータ統計に優れていますが、memcache はデータ キャッシュに優れています。データ構造は制限されています。redis はインメモリ データベースですが、結局のところメモリ領域はハードディスク領域ほど大きくありません。
それぞれに利点と欠点があるため、これらのツールを合成または選択する必要があります。自分のビジネスに合わせて
2. 静的/動的アクセス
可能であれば、CDN を使用します。そうでない場合は、少なくとも静的アクセス層を取得し、Apache、nginx などを使用するかどうかについては、仮想環境にインストールします。自分でマシンを作成し、ストレス テストを行って比較します。
非静的アクセスを動的アクセス層に転送します
3. 論理処理は php
で動的アクセスの入力を引き継ぎ、論理演算を実行します。読み取りと書き込みのためにデータ層に移動します。
別の例として、10 個のデータを並べ替えるために、不必要な foreach ループやコピーなどの愚かなことは行わないでください。 MySQL の select order by を使用し、並べ替えには PHP の関数を使用するだけです。
声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。