、CDNキャッシュ（上流のネットワーク要求）
CDNは、実際には、リソースの分散ストレージとバックアップの方法です。、帯域幅を配布アドレス、サーバーのパフォーマンスは、サイトアクセラレーション、スパイク、オンデマンド、放送や他のシーンのためのアクセスのレイテンシの問題をもたらします。ユーザーがインターネットのネットワークの混雑状況に対処し、応答速度やサイトへのユーザーアクセスの成功率を向上させるために必要なコンテンツを取得するために行くことができるように。
人気の話は、上流ネットワークリソースの要求でユーザーの要求は、近くのユーザに配布することができたときに、Webサーバのキャッシュ上のリソースについての話です。すべてのユーザーが要求されたリソースを使用してWebサーバーに行くことを必要とせずに。
-
従来のWeb要求の処理フロー
ユーザーにアクセスするには1.自分のブラウザに入り、インターネットドメイン
2.ドメイン名を解決するためのローカルDNS（ドメインネームサーバ）サーバへのブラウザ要求
ドメイン名キャッシュが3ローカルDNSサーバーを持っている場合分析の結果、直接の解決要求に対するユーザの応答
4.このドメイン上のローカルDNSサーバのキャッシュの解析結果が存在しない場合は、再帰的に全体的に、結果がブラウザに応答した後に得られたDNSシステムへの要求置き解析された
5。得られたブラウザ名前解決結果、IPドメイン対応するサービス装置であって、
前記ブラウザは、コンテンツサーバに要求する
コンテンツサーバがブラウザにユーザ要求を送信7.
-
CDNのWebリクエスト処理フローの導入後
1ユーザがコンテンツのURLのWebページをクリックし、ローカルDNS解決によるシステムは、DNSは、最終的にはCDN専用のDNSサーバCNAMEポイントの右側にあるドメイン名を解決します。
CDNグローバル負荷分散装置の2.CDNのDNSサーバがIPユーザー返す
URLアクセス要求の熱含量にグローバルCDNへ3.ユーザー負荷分散装置を
ユーザーのIPアドレスに基づいて4.CDNグローバルロードバランシングデバイス、およびユーザーがURLを要求し、ユーザーを選択すると、領域の負荷分散装置に属し、このデバイスへの要求を開始するために、ユーザーことができます
。5.負荷分散装置の面積は、サービスをユーザ提供するために適切なキャッシュサーバを選択します
6.に、ユーザは、ユーザの要求に応じてキャッシュサーバ、キャッシュサーバにリクエストを送信します、ユーザ端末に必要なユーザーコンテンツ
このキャッシュサーバには、コンテンツ、ユーザーが希望しない場合は7.、このサーバは、オリジナルコンテンツサーバにさかのぼるサイトまで、サーバー上のキャッシュからコンテンツを要求しますローカルに引き下げ
二つ、nginxのリバースプロキシ（中間層ネットワーク要求）
nginxのリバースプロキシの役割：
- ロードバランシング：
リバースプロキシと同じ内容（Tomcatなど）を同時にプロキシ複数のアプリケーション・サーバー、クライアントの要求は、各アプリケーションサーバーに配布し、クライアントへの応答を受け取ります
- 静的および動的な分離：
nginxのリバースプロキシ機能を使用すると、リクエストを分散する：アプリケーションサーバへのすべての動的リソースを要求し、直接nginxので返さブラウザに（画像、動画、CSS、JavaScriptファイルなど）の静的リソースに対する要求
一般的なWebサイトのアーキテクチャ設計：
- リバースプロキシ水平拡張機能は、
DNSサーバIPを複数で構成されたドメイン名を解決するために、各アクセスDNSサーバへのDNS解決要求、世論調査：達成するために、「ポーリングDNS」により、プロキシ水平拡張リバースこれらのIPアドレスを返します。
nginxのは、nginxの、限りサーバーの数が増加するなど、時間のボトルネックとなり、新たなサービス展開、外部ネットワークのIPを追加すると、あなたはとても理論的には無限に高い同時実行、パフォーマンスのリバースプロキシ層を拡張することができます。
- 站点层的水平扩展（分布式部署）
站点层的水平扩展，是通过“nginx”实现的。通过修改nginx.conf，可以设置多个web后端。
当web后端成为瓶颈的时候，只要增加服务器数量，新增web服务的部署，在nginx配置中配置上新的web后端，就能扩展站点层的性能，做到理论上的无限高并发。
三、站点的缓存技术（web应用层）
-
1.数据缓存：
对于不会频繁变动而访问量又比较大的数据可以做缓存处理，可以缓存到内存型数据库、客户端等。 -
2.页面静态化：
html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现 -
3.图片服务器分离：
对于Web服务器来说，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的图片服务器。
四、数据库
-
1.硬件优化
-
2.数据库读写分离、主从同步
使用负载均衡实现，写操作都往主库上写，读操作往从服务器上读。 -
3.サブライブラリーサブテーブル
のサブテーブルウェイ
スプリットホライズン（行）、垂直（列）に分割
サブテーブルシーン
Aを：経験によれば、MySQLのテーブルデータは、一般に1万台に達すると、クエリ効率が非常に低くなります。
B：一部のフィールド値と大きなテーブルにはほとんど使用されません。これらのフィールドは、このようなテストの点数などの主要外でリンク別のテーブル、に分離することができ、私たちはしばしば、テストが細部を気にしない、スコアに焦点を当てます。
C：大きなテーブルには、注文、注文フォーム、注文ペイテーブル、注文商品テーブルを開きます。
水平成分ポリシーテーブル
タイムテーブルの並び順：データは月単位で分け、そのようなマイクロブログデータの強力な効果を持っている場合。
プレスセクション部品表：表で、例えば1から1000000 userテーブル、テーブルと二百万から百万。
サブテーブルをハッシュ表は、特定のハッシュアルゴリズムに従って元のターゲットIDまたは名前を格納するデータによって算出されます。 -
4.索引チューニングは
、あまり頻繁に使用してインデックスを使用して列を変更される際に、データの変更、インデックスを再計算しなければならないので、インデックスは、可能ではありません。 -
5.SQLの最適化
1は、関連する列に基づいてCVインデックスによって場所と順序を検討するのは難しいの全表スキャンを回避しよう。
2は、NULL値に避けるべきであるが、where句内のフィールドを決定し、エンジンがインデックスと全表スキャンを使用してあきらめてしまいます。
図3は、where句では避けるべきです！=または<>演算子は、そうでない場合、エンジンは、インデックスとフルテーブルスキャンを使って得ました。
図4は、+％のような、典型的には二重ワイルドカードフルテーブルスキャンをもたらします。 -
6.最適化フィールド
のフィールドタイプおよび制御フィールドの長さなどを使用して妥当な精度を有します。
たとえば、char型のvarchar型を満たすことができないでしょう