PHP の高トラフィックの最適化?

現在、Web サイトのトラフィックが大幅に増加しているため、当社の技術チームの基本的なアイデアは、すべての PHP と MySQL を分離し、途中にキャッシュ層を追加することです。たとえば、メンバー登録は最初にサーバーのメモリに書き込まれ、次にサーバーのメモリに書き込まれます。このために中間キャッシュ層ではどのようなテクノロジーが使用されますか? 返信内容:

mysql の読み取りと書き込みがボトルネックであると感じる場合 (mysql のクエリと書き込みに時間がかかる、または規模が比較的大きい)、確かに中間キャッシュを導入できます。

mysql と PHP の間にキャッシュを構築するには、中間キャッシュ サービスとして redis を直接使用することをお勧めします。

ただし、システムの問題を真に解決するには、mysql の読み取りと書き込みに時間がかかる理由を分析する必要があります。mysql の遅いクエリのログ分析を有効にすることができます。
読み取りと書き込みに問題がある場合は、次の点を試してください。
(1) SQL ステートメントには、テーブル結合やその他の操作が多すぎますか?
(2) テーブル内のレコードが多すぎますか? 何百万ものデータがあり、データベース、テーブル、またはパーティションに分割する必要がありますか?
(3) 適切なインデックスが使用されており、SQL クエリ ステートメントはインデックス フィールドを最大限に活用していますか?
(4) innodb_buffer_pool_size の増加、キャッシュ ヒット率の向上など、mysql 設定パラメータを調整することで、mysql の読み取りおよび書き込みのパフォーマンスを最適化できます。
(5) mysql が単一サーバーにデプロイされている場合は、マスターとスレーブの分離を検討するか、マスターとマスターおよび相互バックアップを設定することができます。
... ...

上記の最適化後も mysql にまだボトルネックがあると感じる場合は、中間キャッシュとして redis を導入しても遅くはありません。

実は、上に書いたことは氷山の一角であり、まだまだ最適化できる箇所がたくさんあります。
初期に書かれた記事:
10 億レベルの Web システムの構築 - 単一マシンから分散クラスターまで
最適化は難しいことではありませんが、適切な薬が必要です。
質問者さん、問題の説明の中で、病気の症状や原因については触れていませんが、すぐに治療計画の策定に移りました: [すべての PHP を MySQL から切り離す...] これは本当にですか?良い？ しかし、私は問題を見守るためにここにいます。 。 。現在のほとんどのメモリ キャッシュは読み取り用に最適化されています。 。 。書き込み最適化の解決策は? ? ?

実は私はその問題に注意を払うためにここに来ました。 。 やみくもに最適化するのではなく、最初に核心を見つける必要があります。

システム速度の低下を引き起こす一般的な書き込みは、通常、頻繁な書き込みをカウントします。たとえば、ページがアクセスされるたびに、pv フィールドが +1 されます。頻繁な書き込みにより、MySQL クエリ キャッシュが作成された直後に期限切れになります。 . これは役割を果たしていないことと同じです。この場合、新しく追加された PV を保存するためのバッファ（非常に頻繁な書き込み、データの一貫性の要件なし）を作成し、バッファがいっぱいになったときに一度に再度書き込むことが非常に適しています。

あなたが言った「
すべての PHP を mysql から切り離し、キャッシュ層を追加する」はあまり良くありません。実際、ほとんどの場合、あなたが呼び出すキャッシュ層は単なるクエリキャッシュ関数です。 mysql を廃止して自分で引き継ぐのはあまり意味がありません。また、登録などの重要なデータはキャッシュに適していません。キャッシュが失われると大変です。 あなたが話している中間層はキューと呼ばれ、これを行うにはredisリストを使用できます。 MySQL の読み書きのビジネス ロジックを最初に最適化するのが最善です。会員登録や登録などの機能はキャッシュする必要があるため、実行が非常に遅くなります。 キャッシュがダウンしました。データはもう必要ありませんか?冗談じゃないよ。 キャッシュは読み取り用に最適化されています。データを書き込むときは間違った方法を使用しないでください。 1. キャッシュ
対象データの変更頻度や読み書き頻度を計画します。
読み取りと書き込みの頻度: 変更頻度の値が大きいほど、キャッシュに適しています。値が小さい場合は、実行しないでください。

2. SQL の最適化。ほとんどのエントリーレベルのシステムのレベルは高くありません...
単一のクエリが大きすぎるかどうか、結合テーブル クエリを単一テーブル クエリに置き換える
MYISAM を INNODB に置き換えるなど...

3. システム アーキテクチャの最適化
単一テーブル クエリ ページに含まれるコンテンツが多すぎませんか?
多くの機能とシステムを異なるビジネス モジュールに分割できますか?

4. 静的ページ
静的ページは、当然、動的ページよりも消費量が大幅に少なくなります
書き込みキューとキャッシュされた一時データ (カウンターなど) ) はすべてこのカテゴリに分類されます

6. 非同期データ取得

7. 分散アーキテクチャ
データベース、複数のデータベース サーバー、さらには複数の PHP サーバーなどの読み取りと書き込みの分離。 この記事を読んですべてを理解してください:
2014-05-07 編集 ボトルネックが必ずしもデータベースにあるわけではない場合があります。まず、それがフロントエンドの問題なのかバックエンドの問題なのかを判断します。フロントエンドの場合は、静的ファイルのキャッシュ、CSS、JS、その他のファイルのマージと圧縮、HTTP リクエストの最小化など、さまざまな最適化を行う必要があります。バックエンド データベースの読み取りおよび書き込みパフォーマンスの問題の場合は、最初にプロファイリングを実行して、ボトルネックがどこにあるのかを特定します。本当にキャッシュ レイヤーを追加したい場合は、データの永続化をサポートする Redis を使用することをお勧めします。さらに、メッセージ キューは、プログラムの分離を実現するために通信を非同期に処理すると考えることができます。メッセージキューは、突然のピークトラフィックに非常にうまく対処できます。個人的には、弊社でも使用している RabbitMQ をお勧めします。データベースへの検索負荷を軽減するために、独立した全文検索エンジンを使用することもできます。私自身も Solr を使用しています。