検索
ホームページバックエンド開発PHPチュートリアルPHP インタビューの質問 7: nginx ロード バランシングを構成する方法

この記事の内容は、PHP インタビューの質問 7 での nginx の負荷分散の設定方法に関するものです。必要な友人に参考にしていただけるように共有します。

nginx 負荷分散には 4 つのモードがあります:

1)、
ポーリング

(デフォルト)

各リクエストは時系列に 1 つずつ異なるバックエンド サーバーに割り当てられ、バックエンド サーバーがダウンした場合は自動的に削除されます。

2)、

体重 ポーリング確率を指定します。重みはアクセス率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。
2)、
ip_hash 各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、各訪問者はバックエンド サーバーに固定的にアクセスできるため、セッションの問題を解決できます。
3)、
公正 (第三者) リクエストはバックエンドサーバーの応答時間に応じて割り当てられ、応答時間の短いリクエストが最初に割り当てられます。
4)、
url_hash (サードパーティ)
設定方法:
nginx.cnf ファイルを開きます

http ノードの下に上流ノードを追加します:

upstream webname {  
  server 192.168.0.1:8080;  
  server 192.168.0.2:8080;  
}

ここで、webname は選択した名前であり、最終的にこの名前が使用されます上記の例のように、URL でアクセスする場合、何も追加しないのがデフォルトのポーリングです。最初のリクエストは最初のサーバーにアクセスし、2 番目のリクエストは 2 番目のサーバーにアクセスします。順番に来てください。

upstream webname {  
  server 192.168.0.1:8080 weight 2;  
  server 192.168.0.2:8080 weight 1;  
}

この重みも分かりやすいですが、重みが大きいほどアクセスされる確率が高くなります。 ip_hash の設定も非常に簡単です。このようにして、同じ IP から来る人は誰でも同じサーバーにアクセスします

次に、サーバー ノードの下で設定します。

upstream webname {  
  ip_hash;  
  server 192.168.0.1:8080;  
  server 192.168.0.2:8080;  
}

proxy_pass は、元の IP アドレスを上で設定した Web 名に置き換えます。

これで基本的に負荷分散設定が完了します。

以下はアクティブとバックアップの構成です:

まだアップストリームにあります

location /name {  
    proxy_pass http://webname/name/;  
    proxy_http_version 1.1;  
    proxy_set_header Upgrade $http_upgrade;  
    proxy_set_header Connection "upgrade";  
}

特定のノードをバックアップとして設定すると、通常の状況ではすべてのリクエストがserver1にアクセスします。server1がハングアップするかビジー状態になると、server2がアクセスされます。 accessed

upstream webname {  
  server 192.168.0.1:8080;  
  server 192.168.0.2:8080 backup;  
}

ノードをダウンに設定すると、このサーバーは負荷に参加しなくなります。

実装例

負荷分散は、トラフィックの多いWebサイトで行う必要があるものです。次に、Nginxサーバーでの負荷分散の設定方法を紹介します。必要な学生に役立つことを願っています。

負荷分散

まず、負荷分散とは何かを簡単に理解しましょう。文字通りに理解すると、N 台のサーバーが負荷を均等に共有し、特定のサーバーの負荷が高いために特定のサーバーがアイドル状態になることがないことを説明できます。状態。したがって、負荷分散の前提は、複数のサーバーで実現できること、つまり 3 台以上のサーバーで十分であるということです。

テスト環境

サーバーがないため、このテストでは指定されたドメイン名を直接ホストし、VMware に 3 つの CentOS をインストールします。

テストドメイン名: a.com

AサーバーIP: 192.168.5.149 (メイン)

BサーバーIP: 192.168.5.27

CサーバーIP: 192.168.5.126

展開アイデア

サーバーはメイン サーバー。ドメイン名はサーバー A (192.168.5.149) に直接解決され、サーバー A はサーバー B (192.168.5.27) とサーバー C (192.168.5.126) に負荷分散されます。

ドメイン名の解決

実際の環境ではないので、ドメイン名はテスト用のa.comになっているだけなので、a.comの解像度はhostsファイルでしか設定できません。

開く:

最後に

upstream webname {  
  server 192.168.0.1:8080;  
  server 192.168.0.2:8080 down;  
}

を追加して保存して終了し、コマンドモードを開始してpingを実行して、設定が成功したかどうかを確認します

スクリーンショットから、a.comは192.168.5.149に正常に解決されました。 IPC:WindowsSystem32driversetchosts

サーバーのnginx.conf設定

nginx.confを開きます。ファイルの場所は、nginxインストールディレクトリのconfディレクトリにあります。

httpセクションに次のコードを追加します

192.168.5.149    a.com

nginxを保存して再起動します

BおよびCサーバーのnginx.conf設定
nginx.confを開き、httpセクションに次のコードを追加します

upstream a.com { 
      server  192.168.5.126:80; 
      server  192.168.5.27:80; 
} 

server{ 
    listen 80; 
    server_name a.com; 
    location / { 
        proxy_pass        http://a.com; 
        proxy_set_header  Host            $host; 
        proxy_set_header  X-Real-IP        $remote_addr; 
        proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for; 
    } 
}

保存してnginxを再起動します

テスト

a.comにアクセスした際に、どのサーバーにリダイレクトされて処理されるかを区別するために、サーバーBとサーバーCにそれぞれ内容の異なるindex.htmlファイルを記述して区別しました。


ブラウザを開いて a.com にアクセスすると、すべてのリクエストがメイン サーバー (192.168.5.149) によってサーバー B (192.168.5.27) とサーバー C (192.168.5.126) に割り当てられ、負荷分散が実現されていることがわかります。 。 効果。

B サーバー処理ページ

C サーバー処理ページ

サーバーの 1 つがダウンした場合はどうなりますか?

サーバーがダウンした場合、アクセスに影響はありますか?

まず例を見てみましょう。上記の例に基づいて、マシン C サーバー 192.168.5.126 がダウンしていると仮定して (ダウンタイムをシミュレートすることは不可能なので、C サーバーをシャットダウンします)、それにアクセスします。また。

アクセス結果:

Cサーバー(192.168.5.126)がダウンしていましたが、Webサイトへのアクセスには影響がなかったことが分かりました。こうすることで、特定のマシンが負荷分散モードでダウンしているためにサイト全体をドラッグダウンすることを心配する必要がなくなります。

如果b.com也要设置负载均衡怎么办?
很简单,跟a.com设置一样。如下:

假设b.com的主服务器IP是192.168.5.149,负载均衡到192.168.5.150和192.168.5.151机器上

现将域名b.com解析到192.168.5.149IP上。

在主服务器(192.168.5.149)的nginx.conf加入以下代码:

upstream b.com { 
      server  192.168.5.150:80; 
      server  192.168.5.151:80; 
} 

server{ 
    listen 80; 
    server_name b.com; 
    location / { 
        proxy_pass        http://b.com; 
        proxy_set_header  Host            $host; 
        proxy_set_header  X-Real-IP        $remote_addr; 
        proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for; 
    } 
}

保存重启nginx

在192.168.5.150与192.168.5.151机器上设置nginx,打开nginx.conf在末尾添加以下代码:

server{ 
    listen 80; 
    server_name b.com; 
    index index.html; 
    root /data0/htdocs/www; 
}

保存重启nginx

完成以后步骤后即可实现b.com的负载均衡配置。

主服务器不能提供服务吗?
以上例子中,我们都是应用到了主服务器负载均衡到其它服务器上,那么主服务器本身能不能也加在服务器列表中,这样就不会白白浪费拿一台服务器纯当做转发功能,而是也参与到提供服务中来。

如以上案例三台服务器:

A服务器IP :192.168.5.149 (主)

B服务器IP :192.168.5.27

C服务器IP :192.168.5.126

我们把域名解析到A服务器,然后由A服务器转发到B服务器与C服务器,那么A服务器只做一个转发功能,现在我们让A服务器也提供站点服务。

我们先来分析一下,如果添加主服务器到upstream中,那么可能会有以下两种情况发生:

1、主服务器转发到了其它IP上,其它IP服务器正常处理;

2、主服务器转发到了自己IP上,然后又进到主服务器分配IP那里,假如一直分配到本机,则会造成一个死循环。

怎么解决这个问题呢?因为80端口已经用来监听负载均衡的处理,那么本服务器上就不能再使用80端口来处理a.com的访问请求,得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码:

server{ 
    listen 8080; 
    server_name a.com; 
    index index.html; 
    root /data0/htdocs/www; 
}

重启nginx,在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问

既然能正常访问,那么我们就可以把主服务器添加到upstream中,但是端口要改一下,如下代码:

upstream a.com { 
      server  192.168.5.126:80; 
      server  192.168.5.27:80; 
      server  127.0.0.1:8080; 
}

由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以,都表示访问自己。

重启Nginx,然后再来访问a.com看看会不会分配到主服务器上。

主服务器也能正常加入服务了。

最后
一、负载均衡不是nginx独有,著名鼎鼎的apache也有,但性能可能不如nginx。

二、多台服务器提供服务,但域名只解析到主服务器,而真正的服务器IP不会被ping下即可获得,增加一定安全性。

三、upstream里的IP不一定是内网,外网IP也可以。不过经典的案例是,局域网中某台IP暴露在外网下,域名直接解析到此IP。然后又这台主服务器转发到内网服务器IP中。

四、某台服务器宕机、不会影响网站正常运行,Nginx不会把请求转发到已宕机的IP上

相关推荐:

php面试题六之memcache和redis的区别

php面试题五之nginx如何调用php和php-fpm的作用和工作原理

php面试题四之实现autoload

以上がPHP インタビューの質問 7: nginx ロード バランシングを構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
PHPセッションを失敗させる可能性のあるいくつかの一般的な問題は何ですか?PHPセッションを失敗させる可能性のあるいくつかの一般的な問題は何ですか?Apr 25, 2025 am 12:16 AM

PHPSESSIONの障害の理由には、構成エラー、Cookieの問題、セッションの有効期限が含まれます。 1。構成エラー:正しいセッションをチェックして設定します。save_path。 2.Cookieの問題:Cookieが正しく設定されていることを確認してください。 3.セッションの有効期限:セッションを調整してください。GC_MAXLIFETIME値はセッション時間を延長します。

PHPでセッション関連の問題をどのようにデバッグしますか?PHPでセッション関連の問題をどのようにデバッグしますか?Apr 25, 2025 am 12:12 AM

PHPでセッションの問題をデバッグする方法は次のとおりです。1。セッションが正しく開始されるかどうかを確認します。 2.セッションIDの配信を確認します。 3.セッションデータのストレージと読み取りを確認します。 4.サーバーの構成を確認します。セッションIDとデータを出力し、セッションファイルのコンテンツを表示するなど、セッション関連の問題を効果的に診断して解決できます。

session_start()が複数回呼び出されるとどうなりますか?session_start()が複数回呼び出されるとどうなりますか?Apr 25, 2025 am 12:06 AM

session_start()への複数の呼び出しにより、警告メッセージと可能なデータ上書きが行われます。 1)PHPは警告を発し、セッションが開始されたことを促します。 2)セッションデータの予期しない上書きを引き起こす可能性があります。 3)session_status()を使用してセッションステータスを確認して、繰り返しの呼び出しを避けます。

PHPでセッションのライフタイムをどのように構成しますか?PHPでセッションのライフタイムをどのように構成しますか?Apr 25, 2025 am 12:05 AM

PHPでのセッションライフサイクルの構成は、session.gc_maxlifetimeとsession.cookie_lifetimeを設定することで達成できます。 1)session.gc_maxlifetimeサーバー側のセッションデータのサバイバル時間を制御します。 0に設定すると、ブラウザが閉じているとCookieが期限切れになります。

セッションを保存するためにデータベースを使用することの利点は何ですか?セッションを保存するためにデータベースを使用することの利点は何ですか?Apr 24, 2025 am 12:16 AM

データベースストレージセッションを使用することの主な利点には、持続性、スケーラビリティ、セキュリティが含まれます。 1。永続性:サーバーが再起動しても、セッションデータは変更されないままになります。 2。スケーラビリティ:分散システムに適用され、セッションデータが複数のサーバー間で同期されるようにします。 3。セキュリティ:データベースは、機密情報を保護するための暗号化されたストレージを提供します。

PHPでカスタムセッション処理をどのように実装しますか?PHPでカスタムセッション処理をどのように実装しますか?Apr 24, 2025 am 12:16 AM

PHPでのカスタムセッション処理の実装は、SessionHandlerInterfaceインターフェイスを実装することで実行できます。具体的な手順には、次のものが含まれます。1)CussentsessionHandlerなどのSessionHandlerInterfaceを実装するクラスの作成。 2)セッションデータのライフサイクルとストレージ方法を定義するためのインターフェイス(オープン、クローズ、読み取り、書き込み、破壊、GCなど)の書き換え方法。 3)PHPスクリプトでカスタムセッションプロセッサを登録し、セッションを開始します。これにより、データをMySQLやRedisなどのメディアに保存して、パフォーマンス、セキュリティ、スケーラビリティを改善できます。

セッションIDとは何ですか?セッションIDとは何ですか?Apr 24, 2025 am 12:13 AM

SessionIDは、ユーザーセッションのステータスを追跡するためにWebアプリケーションで使用されるメカニズムです。 1.ユーザーとサーバー間の複数のインタラクション中にユーザーのID情報を維持するために使用されるランダムに生成された文字列です。 2。サーバーは、ユーザーの複数のリクエストでこれらの要求を識別および関連付けるのに役立つCookieまたはURLパラメーターを介してクライアントに生成および送信します。 3.生成は通常、ランダムアルゴリズムを使用して、一意性と予測不可能性を確保します。 4.実際の開発では、Redisなどのメモリ内データベースを使用してセッションデータを保存してパフォーマンスとセキュリティを改善できます。

ステートレス環境(APIなど)でセッションをどのように処理しますか?ステートレス環境(APIなど)でセッションをどのように処理しますか?Apr 24, 2025 am 12:12 AM

APIなどのステートレス環境でのセッションの管理は、JWTまたはCookieを使用して達成できます。 1。JWTは、無国籍とスケーラビリティに適していますが、ビッグデータに関してはサイズが大きいです。 2.cookiesはより伝統的で実装が簡単ですが、セキュリティを確保するために慎重に構成する必要があります。

See all articles

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

Video Face Swap

Video Face Swap

完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

ホットツール

EditPlus 中国語クラック版

EditPlus 中国語クラック版

サイズが小さく、構文の強調表示、コード プロンプト機能はサポートされていません

Dreamweaver Mac版

Dreamweaver Mac版

ビジュアル Web 開発ツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

MantisBT

MantisBT

Mantis は、製品の欠陥追跡を支援するために設計された、導入が簡単な Web ベースの欠陥追跡ツールです。 PHP、MySQL、Web サーバーが必要です。デモおよびホスティング サービスをチェックしてください。

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール