「高い同時実行性と大規模なトラフィック」アクセスのためのソリューションとソリューションについての詳細な議論

高い同時実行性と大量のトラフィックの問題を解決するにはどうすればよいですか?次の記事では、高い同時実行性と大規模なトラフィックの Web のためのアイデアとソリューションを紹介します。

推奨される関連ビデオ コース: 「 数千万のデータ同時実行ソリューション (理論的実践) 」

高同時実行に関するインタビューの質問を共有します。 15 高同時実行性に関する PHP 面接の質問 (概要)

高同時実行性 Web アーキテクチャ関連の概念

---

• QPS: すべての数インターネット分野における 1 秒あたりのリクエストまたはクエリの数は、1 秒あたりの対応するリクエスト (http リクエスト) の数を指します。

• 1 秒あたりのピーク QPS: (合計 PV の 80%)/(6 時間の秒数の 20%)、訪問の 80% が時間の 20% に集中します

• 同時接続数: システムによって同時に処理されるリクエストの数

• ##スループット: 単位時間あたりに処理されるリクエストの数 (通常は次のように決定されます) QPS と同時実行数)。

• 応答時間: リクエストから応答までにかかる時間。たとえば、システムが HTTP リクエストを処理するのに 100 ミリ秒かかり、この 100 ミリ秒がシステムの応答時間になります。

• PV: ページビューとは、ページビューとクリック数であり、訪問者が 24 時間以内に訪問したページの数です。

• UV: ユニーク訪問者 (UniQue Visitor)、つまり、同じ訪問者が特定の時間範囲内に複数回 Web サイトを訪問し、1 人の独立した訪問者としてのみカウントされます。

• 帯域幅: 帯域幅の計算では、ピーク トラフィックと平均ページ サイズという 2 つの指標に焦点を当てます。

• 毎日の Web サイトの帯域幅 = PV/統計時間 (1 日あたりの秒数に換算) * 平均ページ サイズ (KB 単位) *8。

• ストレス テスト: 最大同時実行性をテストし、最大 QPS をテストします。同時テスト マシンはテスト対象のマシンから分離する必要があることに注意してください。同時テストを実行しないでください。 ab テストが配置されているマシンおよびテスト対象マシンのフロントエンド マシンの CPU、メモリ、ネットワークなどが最大制限の 75% を超えていないことを確認します。
  #同時実行性
  応答速度
  耐障害性

  一般的に使用されるパフォーマンス テスト ツール: ab、wrk、http_load、Web Bench、Siege、Apache JMeter。
高同時実行性と大規模トラフィック Web のための全体的なソリューション

---

トラフィックの最適化

• ##Web リソースのアンチホットリンクにより、サードパーティ システムが画像、CSS、JS などを盗んでサーバー トラフィックやサーバー帯域幅を占有することを防ぎます

• フロントエンドの最適化

• http リクエストの削減: 画像の結合、js の結合、css の結合、圧縮。ファイルは大きくなる可能性がありますが、リクエストは削減されます

• 非同期リクエストの追加: 実際の Ajax 呼び出しインターフェイスを介してデータを取得します

• ブラウザのキャッシュとファイル圧縮を有効にする (nginx 圧縮モジュールを有効にすることもできます)

• cdn アクセラレーション: 帯域不足の問題を解決し、データを cdn にキャッシュします。アクセスするときに最も近いノードを選択することで帯域幅を削減し、アクセスを高速化します。

• 確立独立した画像サーバー: 画像は非常に io 集約的です 画像サーバーと Web を組み合わせることができます サーバーは完全に分離されており、他のサーバーを区別できます 画像サーバーが別個に構築され、コンピューティング型でない場合、構成は画像サーバーもクラスター化可能

• サーバーの最適化

• ページの静的化: 動的ページ、静的 HTML、サーバーの負荷軽減、ページの静的化の浸透、静的化の効果時間

  • 動的言語同時処理:非同期処理、マルチスレッド、キュー非同期処理

  データベースの最適化:

• データベースのキャッシュ: memcache 、redis キャッシュ

• mysql インデックス最適化、mysql サブデータベースとテーブル、mysql パーティション操作、mysql マスター/スレーブ レプリケーションの読み書き分離、mysql ロード バランシング、mysql マスター/スレーブ ホット スタンバイ

• Web サーバーの最適化:

• #負荷分散: ningx のリバース プロキシを使用して負荷分散を使用でき、ネットワーク層の 3 番目の層を使用できます。4 層 LVS は負荷分散を実装します

• ##Web サーバーの負荷分散

##責任の分散

---

4 層ロード バランシング: いわゆる 4 層ロード バランシングは、IP ポート ベースのロード バランシングです。

7 層ロード バランシング: いわゆる 7 層ロード バランシングは、(URL) 情報に基づいたロード バランシングです。
• #7 層ロード バランシングの実装:

債務バランシングNingx のプロキシは非常に強力な機能で、7 層の負荷分散を実現します。強力な機能、優れたパフォーマンス、安定した動作、シンプルで柔軟な構成を備え、動作していないバックエンドを自動的に排除できますサーバー、アップロード ファイルは非同期モードでアップロードでき、複数の配布戦略をサポートし、重みを割り当てることができ、配布方法は柔軟です。

nginx ロード バランシング戦略

IP ハッシュ (組み込み)

加重ポーリング (組み込み)

• 公平な戦略 (拡張子)

• ユニバーサル ハッシュ (拡張子)

• 一貫性のあるハッシュ (拡張子)

1. IP ハッシュ戦略

nginx に組み込まれた別の負荷分散戦略プロセスは、アルゴリズムが同じであることを除いて、ポーリングと非常に似ています。ポーリングとして使用します。特定の戦略は多少変更されています。IP ハッシュ アルゴリズムは、偽装されたポーリング アルゴリズムです。

2. 重み付けポーリング戦略

最初に、リクエストを高重量マシンに割り当てます。 , マシンの重みが他のマシンよりも低い値に低下するまで、リクエストは次の高重みのマシンに割り当てられます。すべてのバックエンド マシンがダウンすると、nginx はすぐにすべてのマシンのフラグを初期値にクリアします。すべてのマシンがタイムアウト状態にならないようにするため

#3. 公平な戦略

#バックエンド サーバーの応答時間に基づいて負荷状況を判断する最も軽いマシンがオフロードに使用されます

ユニバーサル ハッシュと一貫性のあるハッシュ戦略。ユニバーサル ハッシュは比較的単純です。nginx の組み込み変数をハッシュのキーとして使用できます。一貫性のあるハッシュは、構築されたハッシュを使用します。 - 一貫性のあるハッシュ リングで、memcache をサポートします。

4 層の負荷分散は、メッセージ内の宛先アドレスとポートを通じて達成されます。負荷分散デバイスによって設定されたサーバー選択方法に加えて、内部サーバーの最終的な選択を決定します。 lvs 関連用語:

DS:director サーバー ターゲット サーバー、つまり、ロードバランサー

• RS: Real Server 実サーバー、つまりバックエンドサーバー

##VIP: ユーザーに直接接続されている IP アドレス、通常はパブリック IP アドレス
DIP: Director Server Ip は主に内部ホスト通信に使用されます IP アドレス
RIP: Real Server IP Backend realサーバー IP アドレス
CIP:クライアント IP
負荷分散の 3 つの方法:

• NAT: ターゲット IP を変更するアドレスをバックエンド RealServer の IP アドレスに変更します

DR: ターゲット MAC アドレスをバックエンド RealServer の MAC アドレスに変更します

TUNNEL: ほとんど使用されず、リモート災害によく使用されますリカバリ

##4 層と 7 層の負荷分散の長所と短所

##4 層は 7 層よりも大量の同時実行を実行できます。小規模な

7 つのレイヤーを持つ大規模なサイトを使用すると、セッション、動的および静的な分離などに基づいた URL などのより複雑な負荷分散制御を実現できます。7 番目のレイヤーは、多くの部分を占有する可能性があります。 CPU 時間とキャリー同時実行性

cdn アクセラレーション

CDN とは何ですか?

---

ノード: 実サーバーのミラーとして理解できます。

正式名称は Content Delivery Network です。これは、コンテンツ配信ネットワークが、データ伝送の速度と安定性に影響を与える可能性のあるインターネット上のボトルネックやリンクを可能な限り回避し、コンテンツ伝送をより高速かつ安定させることを意味します。 。 ネットワーク全体に配置されたノード サーバーで構成される、既存のインターネットに基づくインテリジェントな仮想ネットワークの層。
cdn システムは、ネットワーク トラフィック、各ノードへの接続、負荷状態、ユーザーまでの距離、応答時間などの包括的な情報に基づいて、ユーザーのリクエストをユーザーに最も近いサービス ノードにリアルタイムでリダイレクトできます。 。

cdn の利点は何ですか?

1. 企業サイト (特に多数の画像や静的ページを含むサイト) のアクセス速度を向上させるローカル キャッシュ アクセラレーション #2. クロスオペレーター ネットワーク アクセラレーションにより、異なるネットワーク上のユーザーが良好なアクセス品質を確保できるようになります

• 3. リモート アクセス ユーザーは、DNS 負荷に基づいてキャッシュ サーバーをインテリジェントかつ自動的に選択しますバランシングテクノロジー

• 4. サーバーのリモートミラー（ミラー）キャッシュサーバーを自動生成し、リモートユーザーがアクセスするとキャッシュサーバーからデータが読み取られるため、リモートアクセスの帯域幅が減少します。 、ネットワーク トラフィックを共有し、サイトの必要性を軽減し、Web サーバーの負荷やその他の機能を提供します。

• #5. 広範囲に分散された CDN ノードとノード間のインテリジェントな冗長性メカニズムにより、ハッカーの侵入を効果的に防止できます。

• ## cdnの動作原理は？

• 従来のアクセス: ユーザーはブラウザにドメイン名を入力してリクエストを開始し、ドメイン名を解決してサーバー IP アドレスを取得し、IP アドレスに基づいて対応するサーバーを見つけます。するとサーバーが応答してデータを返します。

cdn を使用してアクセス: ユーザーはリクエストを開始し、インテリジェントな DNS 分析 (IP に基づいて地理的位置とアクセス ネットワーク タイプを決定し、最短ルートで負荷が最も軽いサーバーを選択します)、キャッシュを取得します。ユーザーは (キャッシュ内に存在する場合) オリジン サイトへのリクエストを開始し、その結果にユーザーにアクセスし、その結果をキャッシュ サーバーに保存します。

cdn に適用できるシナリオは何ですか?

CSS、JS、画像、HTML など、サイトまたはアプリケーション内の多数の静的リソースの配布を高速化する

方法cdnを実装するには？

#BAT などによって実装された CDN サービス

LVS を使用したレイヤー 4 ロード バランシング

7 層のロード バランシングとキャッシュに nginx、varnish、squid、Apache TrafficServer を使用できます。squid をリバース プロキシとして使用するか、nginx をリバース プロキシとして使用します。

#独立した画像サーバーを確立する

---

独立性は必要ですか?

#1. Web サーバーの I/O 負荷を共有し、リソースを消費する画像サービスを分離し、サーバーのパフォーマンスと安定性を向上させます
2. 特に画像サーバーを最適化し、画像サービス向けに対象を絞ったキャッシュ ソリューションを設定し、帯域幅コストを削減し、アクセス速度を向上させることができます。

使用理由独立したドメイン名？

理由: 同じドメイン名での同時ブラウザ接続の数は制限されています。ブラウザ接続の制限を突破すると、Cookie が原因でキャッシュに適していません。ほとんどの Web キャッシュは、Cookie リクエストなしでキャッシュのみを行うため、それぞれの原因が発生します。画像リクエストがキャッシュにヒットしない

#これは独立後の問題ですか?

写真のアップロードと同期方法

• NPS 共有方法

• FTP を使用する同期
動的ページの静的化

関連概念: 動的言語の静的化とは何か、静的である必要がある理由、静的化の実装方法。

---

動的言語の同時処理

---

プロセスとは

プロセスは、特定のデータ セット上でコンピュータ内のプログラムを実行するアクティビティです。これは、システム内のリソース割り当てとスケジューリングの基本単位であり、オペレーティング システム構造の基礎です。

Aプロセスは「実行プログラム」です。

プロセスの状態の 3 状態モデル

マルチプログラミング システムでは、プロセスはプロセッサ上で交互に実行され、状態は連続的に変化します。

実行中: プロセスがプロセッサ上で実行されているとき、そのプロセスは実行状態にあると言われます。この状態のプロセスの数はプロセッサの数以下です。シングルプロセッサ システムの場合、実行状態のプロセスは 1 つだけです。他のプロセスを実行できない場合 (たとえば、すべてのプロセスがブロックされている場合)、通常はシステムのアイドル プロセスが自動的に実行されます。

• Ready: プロセスがプロセッサーを除くすべてのリソースを取得し、プロセッサーを取得すると実行できる場合、そのプロセスは準備完了状態であると言われます。準備完了状態は、複数の優先順位に従ってキューに入れることができます。たとえば、プロセスがタイム スライスの不足により準備完了状態になると、そのプロセスは優先度の低いキューに配置され、プロセスが I/O 操作の完了により準備完了状態になると、キューに配置されます。優先度の高いキュー。

• ブロッキング: 待機状態またはスリープ状態とも呼ばれ、プロセスは特定のイベントが発生するのを待っています (I/O の要求や I/O の完了の待機など)。これは、プロセスにプロセッサが割り当てられていても実行できないため、プロセスはブロックされた状態と呼ばれます。

スレッドとは

ユーザーの同時リクエストのため、明らかに、スレッドのプロセスを作成しても問題ありません。システム リソースのオーバーヘッドやユーザー リクエストへの応答効率の観点からすると、これは意味がありません。そこで、オペレーティング システムにスレッドの概念が導入されました。

スレッドは軽量プロセスとも呼ばれ、プログラム実行フローの最小単位です。

スレッドはプロセス内のエンティティであり、システムによって独立してスケジュールされ割り当てられる基本単位です。スレッド自体はシステム リソースを所有せず、動作に必要な一部のリソースのみを所有しますが、他のスレッドと同じプロセスに属し、プロセスが所有するすべてのリソースを共有します。

スレッドは別のスレッドを作成したりキャンセルしたりすることができ、同じプロセス内の複数のスレッドを同時に実行できます。

スレッドは、プログラム内の単一の逐次制御プロセスです。プロセス内の比較的独立したスケジュール可能な実行単位。システムが独立して CPU をスケジュールし、割り当てるための基本単位です。実行中のプログラムのスケジューリング単位を指します。

スレッドの 3 つの状態

準備完了状態: スレッドは実行のためのすべての条件を備えており、論理的に実行でき、プロセッサを待機しています。

• 実行ステータス: プロセッサを占有しているスレッドは実行中です。

• ブロッキング状態: スレッドはイベント (セマフォなど) を待っており、論理的に実行できません。

コルーチンとは何ですか?

コルーチンはユーザー モードの軽量スレッドです。スケジューリングは完全にユーザーの制御下にあります。 。コルーチンには独自のレジスタ コンテキストとスタックがあります。調整スケジュールの切り替え時には、レジスタコンテキストとスタックが別の場所に保存され、切り替え時に元に保存されていたレジスタコンテキストとスタックが復元されます スタックを直接操作する場合、基本的にカーネル切り替えのオーバーヘッドはなく、グローバル変数へのアクセスはカーネル切り替えなしで可能ですロックしているため、コンテキストの切り替えが非常に高速です。

スレッドとプロセスの違いは何ですか?

#1. スレッドはプロセス内の実行単位です。プロセス内には少なくとも 1 つのスレッドがあり、プロセスのアドレス空間を共有します。そしてプロセスには独自の独立したアドレス空間があります。

• 2. プロセスはリソースの割り当てと所有権の単位であり、同じプロセス内のスレッドはプロセスのリソースを共有します。

• 3. スレッドはプロセッサ スケジューリングの基本単位ですが、プロセスはそうではありません

• 4. 両方は同時に実行できます

• 5. それぞれの独立したスレッドには、プログラム実行のエントリ ポイント、順次実行シーケンス、およびプログラムの終了ポイントがあります。ただし、スレッドは独立して実行できず、アプリケーション プログラムに依存する必要があります。アプリケーション プログラムは、マルチスレッド実行制御。

#スレッドとコルーチンの違いは何ですか?

• 1. スレッドは複数のコルーチンを持つことができ、プロセスは独立して複数のコルーチンを持つこともできます

• 2.スレッド プロセスはすべて同期メカニズムですが、コルーチンは非同期です

• 3. コルーチンは最後の呼び出しの状態を保持できます。プロセスが再入するたびに、それは、最後の呼び出しの状態

マルチプロセスとは何ですか?

同時に、同じコンピュータ システム内で 2 つ以上のプロセスの実行が許可されている場合、これは、複数のプロセスがもう 1 つのプロセスを開いて、もう 1 つのリソースを割り当てることを意味します。・プロセス通信が不便

#マルチスレッドとは何ですか?

スレッドはプロセスを多くのスライスに分割します。各スライスは独立したプロセスにすることができます。マルチプロセスとの違いは、1 つのプロセスのリソースのみが使用され、スレッドは通信できることです。

複数の概念の違いは何ですか?

• 単一プロセスと単一スレッド: テーブルで食事をする 1 人のユーザー

• 単一プロセスとマルチスレッド: 複数人々がテーブルで食べ物を食べる

• 複数のプロセスと単一のスレッド: 複数の人々がそれぞれ自分のテーブルで食べ物を食べる

# #同期ブロッキング モデル

複数のプロセス: 最も初期のサーバー側プログラムは、マルチプロセスとマルチスレッドを通じて同時 IO の問題を解決しました。リクエストによってプロセスが作成され、次に子プロセスが作成されます。プロセスがループ同期に入る ブロックされた方法でクライアント接続と対話し、処理データを送受信します。

手順

• ソケットの作成

• while ループに入り、プロセス受け入れでブロックします操作では、クライアント接続がメインプロセスに入り、マルチプロセスモデルの下でフォークを通じて子プロセスを作成するのを待ちます。

サブスレッドはマルチスレッド モードで作成できます

サブスレッド/スレッドが正常に作成されると、while ループに入り、recv でブロックされます。

データを受信した後、サーバー プログラムはそれを処理し、send を使用してクライアントに応答を送信します。クライアント接続が閉じられ、子プロセス/スレッドが終了し、すべてのリソースが破棄されます。メインプロセス/スレッドは、この子プロセス/スレッドをリサイクルします。

このモデルは、同時実行性の問題を解決するためにプロセスの数に大きく依存しています。

多数のプロセスを開始すると、プロセス スケジューリングの消費がさらに増加し​​ます

非同期ノンブロッキング モデル

現在、さまざまな高同時非同期 IO のサーバー プログラムはすべて epoll に基づいて実装されています。

IO 多重化非同期ノンブロッキング プログラムは、古典的な Reactor モデルを使用します。Reactor は、名前が示すように、リアクターを意味し、データは処理しません送信と受信。ソケット ハンドルのイベント変更のみを監視できます。

Reactor モデル:

- add：添加一个socket到reactor
- set：修改socket对应的事件，如可读可写
- del：从reactor中移除
- callback：事件发生后回掉指定的函数

nginx: マルチスレッド Reactor

swoole: マルチスレッド Reactor マルチプロセス ワーカー

PHP 同時プログラミングの実践

##1.php の swoole 拡張機能、純粋な C 言語で書かれた並列高性能ネットワーク通信エンジンは、非同期マルチスレッドを提供します。 PHP 言語では、サーバー、非同期 tcp/udp ネットワーク クライアント、非同期 mysql、非同期 redis、データベース接続プール、AsyncTask、メッセージ キュー、ミリ秒タイマー、非同期ファイルの読み取りと書き込み、非同期 DNS クエリ。

---

• 
  

  2. 非同期 IO のサポートに加えて、swoole は PHP マルチプロセス モード用に複数の同時データ構造と IPC 通信メカニズムを設計しました。プログラミング作業

• 3.swoole2.0 は Go 言語に似たコルーチンをサポートし、完全同期コードを使用して非同期プログラムを実装できます

• 4. メッセージ キュー

• 5. アプリケーションの切り離し

• シナリオの説明: ユーザーが注文した後、注文システムはユーザーに通知する必要があります。在庫システム。

• 在庫システムにアクセスできない場合、注文削減在庫が失敗し、注文が失敗します

• 在庫から注文システムを切り離すsystem

• Reference Queue

• ユーザーが注文すると、注文システムは永続化処理を完了し、メッセージをメッセージ キューに書き込み、ユーザーの注文が正常に返されます

• 注文情報をサブスクライブし、プル/プッシュ メソッドを使用して注文情報を取得します。在庫システムは注文情報に基づいて在庫操作を実行します

• 6. トラフィックのピークカット アプリケーション シナリオ: フラッシュ販売活動、トラフィックが瞬時に急増し、サーバーに大きな負荷がかかる ユーザーがリクエストを開始すると、サーバーはリクエストを受信して​​メッセージに書き込みます最初に列に並びます。メッセージ キューの長さが最大値を超える場合は、エラーが直接報告されるか、リクエスト量を制御して高トラフィックを軽減するようユーザーに求められます

• 7.日志处理 应用场景：解决大量日志的传输 日志采集程序将程序写入消息队列，然后通过日志处理程序的订阅消费日志。

• 8.消息通讯 聊天室

• 9.常见消息队列产品 kafka，ActiveMQ，ZeroMQ，RabbitMQ，Redis等 php的异步 消息队列

• 10.接口的并发请求 curl_multi_init

mysql缓存层的优化

---

1.什么是数据库缓存

mysql等一些常见的关系型数据库的数据都存储在磁盘当中，在高并发场景下，业务应用对mysql产生的增删，改，查的操作造成巨大的I/O开销和查询压力，这无疑对数据库和服务器都是一种巨大的压力，为了解决此类问题，缓存数据的概念应运而生。

• 极大的解决数据库服务器的压力

• 提高应用数据的响应速度

常见的缓存形式：内存缓存和文件缓存

2.为什么要使用数据库缓存

• 缓存数据是为了让客户端很少甚至不访问数据库服务器进行数据的查询，高并发下，能最大程序地降低对数据库服务器的访问压力。

• 用户请求-》数据查询-》连接数据库服务器并查询数据-》将数据缓存起来（html，内存，json，序列化数据）-》显示给客户端

• 缓存方式的选择

• 缓存场景的选择

• 缓存数据的实时性

• 缓存数据的稳定性

3.使用mysql查询缓存

• 启用mysql查询缓存

• 极大的降低cpu使用率

• query_cache_type查询缓存类型，有0，1，2三个取值。0则不适用查询缓存。1表示始终使用查询缓存，2表示按需使用查询缓存。

query_cahce_type=1 select SQL_NO_CACHE * from my_table where condition; query_cache_type=2 select SQL_CACHE * from my_table where condition; query_cache_size

默认情况下query_cache_size为0，表示为查询缓存预留的内存为0，则无法使用查询缓存 SET GLOBAL query_cache_size = 134217728; 查询缓存可以看作是SQL文本和查询结果的映射 第二次查询的SQL和第一次查询的SQL完全相同，则会使用缓 SHOW STATUS LIKE ‘Qcache_hits’查看命中次数 表的结构和数据发生改变时，查询缓存中的数据不再有效

情理缓存：

• FLUSH QUERY CACHE;//清理查询缓存内存碎片

• RESET QUERY CACHE;//从查询缓存中移出所有查询

• FLUSH TABLES；//关闭所有打开的表，同时该操作将会清空查询缓存中的内容

4.使用Memcache缓存

对于大型站点，如果没有中间缓存层，当流量打入数据库层时，即便有之前的几层为我们挡住一部分流量，但是在大并发的情况下，还是会有大量请求涌入数据库层，这样对于数据库服务器的压力冲击很大，响应速度也会下降，因此添加中间缓存层很有必要。

memcache是一套分布式的高速缓存系统，由liveJournal的BrandFitzpatrick开发，但目前被许多网站使用以提升网站的访问速度，尤其对于一些大型的、需要频繁访问数据库的网站访问速度提升效果十分显著。 memcache是一个高性能的分布式的内存对象缓存系统，通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像，视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存，然后从内存中读取，从而大大提高读取速度。

工作流程：先检查客户端的请求数据是否在memcache中，如有，直接把请求数据返回，不再对数据库进行任何操作；如果请求的数据不在memcache中，就去查数据库，把从数据库中获取的数据返回给客户端，同时把数据缓存一份到memcached中。

通用缓存机制：用查询的方法名+参数作为查询时的key，value对中的key值

5.使用Redis缓存

与memcache的区别：

• 性能相差不大

• redis在2.0版本后增加了自己的VM特性，突破物理内存的限制，memcache可以修改最大可用内存，采用LRU算法

• redis依赖客户端来实现分布式读写

• memcache本身没有数据冗余机制

• redis支持（快照，aof）依赖快照进行持久化aof增强了可靠性的同时，对性能有所影响

• redis用户数据量较小的高性能操作和运算上

• memcache用于在动态系统中减少数据库负载，提升性能；适合做缓存提高性能。

• 可用于存储其他数据：session，session_set_save_handler

mysql データ層の最適化

---

• データ テーブルのデータ型の最適化: int、smallint.、bigint、enum、 IP ストレージは int 型 ip2long を使用して変換および保存します。
  

• #インデックスの数が多いほど良いため、適切なフィールドに適切なインデックスを作成します。

• ##Complyインデックスのプレフィックス原則を使用

• #Like query%問題

• #フルテーブルスキャンの最適化
  # #or 条件付きインデックスの使用法

• 文字列型インデックスの失敗の問題

• データ クエリ中のデータ アクセスを最適化する、使用制限、* を使用しないようにする、複雑なものを単純にする、クエリを分割する、関連するクエリを分解する *

• 特定の種類のクエリ ステートメントの最適化、count() の最適化、関連するクエリ ステートメントの最適化、サブクエリの最適化、グループ化と個別の最適化、制限と共用体の最適化

• ストレージ エンジンの最適化: innodb を使用してみる

• データベース テーブル構造の最適化: パーティション操作 (ユーザーに対して透過的)パーティション、サブデータベース、テーブル (水平分割、垂直分割によるセカンダリ テーブル作成)

• データベース サーバー アーキテクチャの最適化: マスター/スレーブ レプリケーション、読み取り/書き込み分離、デュアル アクティブ ホット スタンバイ、負荷分散 (lvs は負荷分散を実現し、MyCat データベース ミドルウェアは負荷分散を実現します)