「インターネットアーキテクチャ」ソフトウェアアーキテクチャ-nginx(パート2)

今日は引き続きnginxについてお話します。以前はnginxの構成についてのみ紹介しましたが、今回は主にnginxの本番環境の構成と本番環境での構成方法について説明します。ソースコード:https://github.com/limingios/netFuture/tree/master/nginx

システムタイプ IPアドレス ノードの役割 CPU 記憶 ホスト名
Centos7 192.168.66.110 nginx 1 2G nginx
Centos7 192.168.66.111 Tomcat 1 2G tomcat1
Centos7 192.168.66.112 Tomcat 1 2G tomcat2

Nginxはどのように高速キャッシュを実装しますか(1)

シーン紹介

あなたが全国に面した大規模なプロジェクトを行っていて、建築家に対する会社の要件が700以上のQPSを達成することであると仮定します。

  • あなたがウェブサイトの開発について知る必要があるいくつかのキーワードを紹介します
  1. 応答時間(RT)

応答時間とは、システムが要求に応答する時間を指します。

  1. スループット(TPS)

単位時間内にシステムによって処理された要求の数

  1. 同時ユーザー

システムが同時に実行できるシステム機能を通常使用できるユーザーの数

  1. 1秒あたりのQPSクエリレート

特定のクエリサーバーが指定された時間内に処理するトラフィック量の測定

  • 次のウェブサイトの一般的な実際のhtmlサイズを理解する

技術ブログを開く:idig8.com

ソースコードを見る

ファイルサイズで保存:45kb、700QPS / s = 700 * 45/1024 = 30MB、700QPSの場合、1ページで30MB / sを吐き出す必要があります。結局のところ、個人のブログはそれに耐えられないはずです。

image.png

ある会社を例にとってみましょう。ファイルサイズは186kb、700QPS / s = 700 * 186/1024 = 100MB +で保存されます。1ページが700QPSの場合、100MB / sを吐き出す必要があります。これはすばらしいことです。 。

JD.comを設計する場合は、設計方法を理解する必要があります。

  • 製品詳細ページには、次の主なサービスが含まれます。
  1. 製品詳細ページHTMLページレンダリング
  2. 価格サービス
  3. プロモーションサービスの在庫状況/サービスアドワーズサービスへの配信
  4. プレセール/セキルサービス
  5. 評価サービス
  6. トライアルサービス
  7. サービスをお勧めします
  8. 商品紹介サービス各カテゴリーに関連するいくつかの特別サービス

上記はすべてマイクロサービスになります。

  1. Ajaxを使用して、価格、広告、在庫、その他のサービスを動的にロードします
  2. キー値を使用して、詳細ページのメインHTMLをキャッシュします。

多くの比較的大規模な内部システムは、このように設計されています。

マイクロサービスとマイクロサービスはどちらもギガビット帯域幅のイントラネットでしたが、マイクロサービスから取得されたのはこれが初めてでした。その後、それらはすべてredisを直接通過しました。特別なデータはajaxを介して行われます。redisからの取得は間違いなく大幅に向上します。このケースを使用した場合でも500qpsは可能ですが、上昇したい場合は基本的に手に入れるのは困難です。しかし、私たちの要件は700qpsになります。

500QPSに達すると圧力試験を継続することは困難です。

理由を分析します。詳細ページのhtml本体は平均150kbに達するため、500QPSはLANブロードバンドの制限に近づいています。75MB以上の場合、内部ネットワークの帯域幅は一般にギガビットで、1000年の帯域幅は128MB /秒です。実際、これは内部ネットワークIOのボトルネックでもあります。上の図のアーキテクチャでは、イントラネットは実際に2回アクセスされています。1つはnginxを介して製品詳細サービスにアクセスするためのもので、もう1つは詳細サービスを介してredisにアクセスするためのものです。

  • 上記の2つのイントラネット通信を解決するための最も理想的な方法を解決したい場合は、上の図の2つのノードなしで実行できます。

redisキャッシュを使用したり、nginxを介して製品詳細ページサービスを要求したりしないでください。nginxローカルハードディスクキャッシュから直接アクセスしてください。イントラネット通信のボトルネックは解決されますか?

  • 解決

内部ネットワーク通信を減らすために、nginx自体も構成を通じてローカルハードディスクにデータをキャッシュでき、次のリクエストはnginxの内部ハードディスクキャッシュデータを直接要求します。これにより、内部ネットワーク通信も減少します。

通常の状況では、これはキャッシュを伴うプロセスです。

通常の状況でキャッシュがない場合、nginxは自動的にキャッシュを追加します

製品が変更された場合の対処方法は、MQメッセージサービス、詳細ページサービス、および詳細ページサービスを使用して、統一された方法で直接アドレスを要求し、nginxの下のキャッシュをクリアすることです。

nginxキャッシュ構成

  • nginxでキャッシュを構成する方法

proxy_cacheは、プロキシモードで使用されるキャッシュ関数です(一般にアンチジェネレーションとも呼ばれます)

events {
    
    
    worker_connections  1024;
}


http {
    
    
      include       mime.types;
      default_type  application/octet-stream;
      sendfile        on;
      keepalive_timeout  65;
#配置缓存
      proxy_cache_path /data/nginx/cache_item levels=1:2 keys_zone=cache_item:200m inactive=30d max_size=10g;
   
      upstream idig8 {
    
    
        server 192.168.66.111:8080       weight=5;
        server 192.168.66.112:8080       weight=5;
     }

   server {
    
    
        listen       80;
        server_name  localhost;


        location / {
    
    
            root   html;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
    
    
            root   html;
        }
        
        #配置缓存
        location ~*\.(html|htm)$ {
    
    
          proxy_set_header Host $host;
          proxy_set_header X-Forwarded-For $remote_addr;
          proxy_pass http://idig8;
          proxy_cache cache_item;
          proxy_cache_key $host$uri$is_args$args;
          proxy_cache_valid 200 304 12h;
          expires 7d;
        }
    }

}

image.png

  • tomcatディレクトリに新しいindex.htmlを作成します

tomcat1

idig8.com
192.168.66.111

tomcat2

idig8.com
192.168.66.112

  • nginxを再起動します
./sbin/nginx -s stop
mkdir -p /data/nginx/cache_item
./sbin/nginx
  • キャッシュパスを表示
pwd
cd /data/nginx/cache_item/3/cf
ls

  • キャッシュを空にしてください

効果を見る

変更されたindex.html

リクエストまたはキャッシュ内のデータ

プログラムのNginx構成実装を構成する方法を確認します

1、在http元素下添加缓存区声明。
proxy_cache_path /data/nginx/cache_item levels=1:1:2 keys_zone=cache_item:500m
inactive=30d max_size=10g;
2、为指定location 设定缓存策略。
proxy_cache cache_item;
proxy_cache_key $host $uri$is_args$args;#以全路径md5值做做为Key
proxy_cache_valid 200 304 12h; #对不同的HTTP状态码设置不同的缓存时间
expires 7d; #总体缓存时间

キャッシュの効果的なプロセスを示します

  1. 宣言キャッシュパスを構成する
  2. 場所のキャッシュ戦略を構成する
  3. nginxを再起動します(変更)
  4. キャッシュディレクトリの生成を表示する
親要素 名前 説明
http proxy_cache_path キャッシュのルートパスを指定します
レベル キャッシュディレクトリの最上位レベルは3で、各レベルは1〜2文字で表されます。たとえば、1:1:2は3つのレイヤーを意味します。
keys_zone キャッシュブロック名とメモリブロックサイズ。cache_itemなど:500m。cache_itemという名前のサイズが500mであることを示します。サイズを超えると、最も古いデータが消去されます。
非活性 次のような最長のアイドル時間:10dデータが10日間アイドル状態の場合、データはクリアされます
max_size キャッシュ領域内のハードディスクの最大サイズ。アイドル状態を超えるデータはクリアされます
ロケーション proxy_cache keys_zoneで設定された値に対応するキャッシュ領域を指定します
proxy_cache_key 次のようなパラメータを使用してキャッシュキーをアセンブルします。hosturiis_argsargs、フルパスのmd5値がキーとして使用されます
proxy_cache_valid さまざまなステータスコードのキャッシュ有効期間を設定します
  • キャッシュをクリアします。

この関数は、サードパーティのモジュールngx_cache_purgeによって実装できます。ngx_cache_purgeをNginxにコンパイルして、指定したURLのキャッシュをクリアします。

  • ngx_cache_purgeモジュールをnginxに追加します
cd ~
wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz
#查看已安装模块
~/nginx/sbin/nginx -V
#进⼊nginx安装包⽬录 重新安装 --add-module为模块解压的全路径
cd ~/nginx-1.13.10
./configure --prefix=/root/nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/root/ngx_cache_purge-2.3
#重新编译
make
cp /root/nginx-1.13.10/sbin/nginx ~/nginx/sbin/nginx 

#查看是否安装成功
./nginx/sbin/nginx -t

明確な構成

location ~ /purge(/.*) {
    
    
#允许访问的IP
allow 127.0.0.1;
allow 192.168.0.193;
#禁⽌访问的IP
deny all;
#配置清除指定缓存区和路径(与proxy_cache_key⼀⾄)
proxy_cache_purge cache_item $host$1$is_args$args;
}

Nginxはどのようにホットリンクを防ぎますか(2)

質問:
写真のヒル防止とは何ですか?これは、このサイトだけがこのサイトの写真、CSS、その他のリソースにアクセスでき、他のサイトはそれを開くことができないことを意味します!
この機能をJAVAに実装するにはどうすればよいですか?非常に簡単です。リクエストヘッダーのリファラー属性が指定されたドメイン名であるかどうかを確認するだけです。
Nginxの原理は似ています。

location ~* \.(gif|png|jpg|swf|flv)$ {
    
    
root html;
valid_referers none *.tl.com;
if ($invalid_referer) {
    
    
rewrite ^/ http://www.tl.com/image/403.png;
#return 404;
}
}

説明:valid_referers条件が渡されない場合、nginxはinvalid_refererをtrueに割り当てます。
構文:valid_referers none | blocked | server_names | string…;
パラメーターの説明:
none
は「Referer」を許可しませんソースヘッダーが空の場合、
blocked
は許可しません「Referer」値が空の場合、Refererの値がプロキシまたはファイアウォールによって削除される可能性があります
。server_names
「Referer」ソースヘッダーには、現在のserver_names(現在のドメイン名)が含まれている必要があります。

クイックネットワークシティサイトの構成と同様に、Nginxはサブドメインサイトの構成をどのように実装しますか(3)

各サブドメインが静的サイトに対応する必要がある場合があります(58 Daojia、Youzanモールなどと同様)。毎日ドメイン名
追加するのはかなり面倒です。nginxでは、$ hostに基づいて対応するディレクトリに直接接続できます。具体的な構成は次のとおりです。

server {
    
    
listen 80;
server_name *.tl.com;
root /data/www/$host;
access_log logs/$host.access.log;
location / {
    
    
index index.html;
}
}

ホストファイルに依存するホストのホストファイルを必ず変更してください。

PS:一般的に、nginxはリバースプロキシとして使用されることが多く、実際、多くの特別な構成が大規模なインターネットeコマース企業で使用されることがよくあります。したがって、このキャッシュと盗難防止リンクも優れた機能です。

おすすめ

転載: blog.csdn.net/zhugeaming2018/article/details/111479723