この記事の内容は、PHP インタビューの質問 7 での nginx の負荷分散の設定方法に関するものです。必要な友人に参考にしていただけるように共有します。
nginx 負荷分散には 4 つのモードがあります:
1)、
ポーリング
各リクエストは時系列に 1 つずつ異なるバックエンド サーバーに割り当てられ、バックエンド サーバーがダウンした場合は自動的に削除されます。
2)、体重
ポーリング確率を指定します。重みはアクセス率に比例し、バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。
2)、
ip_hash
各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、各訪問者はバックエンド サーバーに固定的にアクセスできるため、セッションの問題を解決できます。
3)、
公正 (第三者)
リクエストはバックエンドサーバーの応答時間に応じて割り当てられ、応答時間の短いリクエストが最初に割り当てられます。
4)、
url_hash (サードパーティ)
設定方法:
nginx.cnf ファイルを開きます
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
サーバーはメイン サーバー。ドメイン名はサーバー 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ディレクトリにあります。
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 サーバー処理ページ
サーバーがダウンした場合、アクセスに影響はありますか?
まず例を見てみましょう。上記の例に基づいて、マシン 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面试题五之nginx如何调用php和php-fpm的作用和工作原理
以上がPHP インタビューの質問 7: nginx ロード バランシングを構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

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

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

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

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

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

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

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

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


ホットAIツール

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

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

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

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

人気の記事

ホットツール

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

Dreamweaver Mac版
ビジュアル Web 開発ツール

メモ帳++7.3.1
使いやすく無料のコードエディター

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

ドリームウィーバー CS6
ビジュアル Web 開発ツール

ホットトピック









