本文介绍Windows系统下安装Nginx服务器，希望对于初学Nginx服务器相关的朋友有帮助，更多Nginx安装、配置、报错处理等资源请本站内搜索。。
第一步 下载nginx ，windows版本,解压保存在C:/nginx下( 用的1.0.3版)
第二步 下载 php fast-cgi版本(我用的是 VC9 x86 Non Thread Safe），解压到C:/php下
第三步 把C:/php/php.ini-development重命名成C:/php/php.ini，找到#cgi.fix_pathinfo=1,把#号去掉
第四步 修改C:/nginx/conf/nginx.conf
下面是我的简单配置:
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
#root html; //此处为默认路径
root D:/public_html; //此处为我修改，要运行PHP程序的路径
index index.php index.html index.htm; //增加了 index.php
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ .php$ {
# root php;
#index index.php
#proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ .php$ {
root D:/public_html; //运行的PHP程序路径
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php; //默认首页程序
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; //$document_root 指的是上面的 D:/public_html
include fastcgi_params;
}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443;
# server_name localhost;
# ssl on;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_timeout 5m;
# ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
第五步 ，PHP以fast-cgi形式运行
php-cgi.exe -b 127.0.0.1:9000 -c d:/nginx/php/php.ini
在CMD下运行下面（路径可能有些不同)
第六步 点击运行 nginx.exe ，运行nginx
第七步 浏览器中输入 localhost/index.php，就运行D:/public_html/index.php这个程序了
start_nginx.bat，用于同时启动 PHP FastCGI 和 Nginx：@echo off
echo Starting PHP FastCGI...
RunHiddenConsole c:/php/php-cgi.exe -b 127.0.0.1:9000 -c c:/php/php.ini
echo Starting nginx...
d:/nginx/nginx.exe
RunHiddenConsole.exe 是一个用来隐藏 DOS 窗口的小程序，可以在这里下载RunHiddenConsole.zip (1.01 kb)。
start_nginx.bat 开启后，也会有 DOS 窗口，但是可以安全的关掉，并不会关闭 Nginx 和 php-cgi.exe。
stop_nginx.bat，用来关闭：
@echo off
echo Stopping nginx...
taskkill /F /IM nginx.exe > nul
echo Stopping PHP FastCGI...
taskkill /F /IM php-cgi.exe > nul
exit
nginx/windows: 让nginx以服务的方式运行-
---------------------------chinaunix.net-----------------------------------------------------
在windows下安装了nginx, 郁闷是发现它没有以服务方式运行, 也就是说当用户注销后,程序
会终止.因此需要将nginx作为服务运行.
假设nginx安装在c:nginx下:
1.下载微软服务注册工具srvany.exe, instsrv.exe, 存放到c:nginx目录下
http://eastedu.bl-changjiang.com/UploadFiles/2006-5/511179043.rar
2.安装NGINX服务, 将命令行切换到c:nginx,执行下列命令
instsrv NGINX c:nginxsrvany.exe
3.在c:nginx下,编辑一个nginx.reg文件
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNGINXParameters]
"Application"="C:nginxnginx.exe"
"AppParameters"=""
"AppDirectory"="C:nginx"
5.让服务与程序关联起来, 命令行执行
6.编辑启动nginx脚本start-nginx.bat(关闭脚本不用变), 让程序以服务方式运行
@ECHO OFF
net stop nginx
net start nginx
EXIT
nginx负载均衡中RR和ip_hash策略分析
一、nginx的upstream目前支持负载均衡方式的分配
1、RR（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
例如：
upstream tomcats {
server 10.1.1.107:88 max_fails=3fail_timeout=3s weight=9;
server 10.1.1.132:80 max_fails=3fail_timeout=3s weight=9;
}
2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
例如：
upstream tomcats {
ip_hash;
server 10.1.1.107:88;
server 10.1.1.132:80;
}
3、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
4、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
下面，我们针对RR和ip_hash的负载均衡策略进行分析。因为每一种负载均衡策略都是在upstream的框架中使用，upstream控制总的工作流程，负载均衡策略仅仅提供选择或释放server的函数，所以，我们在分析RR时结合upstream（ngx_http_upstream.c）。 ip_hash大部分内容与RR一致，只是重新实现RR中的ngx_http_upstream_get_peer函数。
二、RR策略
RR机制分为三个部分：初始化upstream，获取一个可用的后台服务器和释放后台服务器。
以下分析以此配置为例:
upstreambackend {
server A max_fails=3 fail_timeout=4s weight=9;
server B max_fails=3 fail_timeout=4s weight=9;
server C max_fails=3 fail_timeout=4s weight=9;
server D backup;
Server E backup;
}
2.1 初始化upstream
对于例子中的upstreambackend来说，
首先初始化各个server,除了设置IP和端口号外，还要设置如下置weight，current_weight，max_fails和fail_timeout。其中max_fails和fail_timeout 这两个参数是组合使用的，表示server 如果失败次数达到max_fails 次，并保持fail_timeout秒之内该服务器不能被访问。
对于serverA来说，设置如下
serverA.weight =9;
serverA.current_weight= 9; //初始值等于配置文件中的weight.
serverA.max_fails = 3;
serverA.fail_timeout =4;
接着，创建两个server类型（在下文介绍中，server类型等同于peer类型，都是用来指明存储upstream中一个server的信息）的数组，peers和backup，分别存储正常的轮循server和备用server.并且，按照数组中各个server的weight值的大小，由高到底排序。
本例中，在数组peers中存储serverA、serverB和serverC, 并记录server的总个数peers->number=3;在数组backup中存储serverD和 serverE, 并记录server的总个数backup->number=2;
最后，设置upstream中各个变量的值。
rrp 表示当前要轮循的server数组，初始设置为Upstream->rrp= peers.
tries 表示尝试的次数，当尝试一个server失败后，tries的值就会减一。初始设置为peers的总个数。
Next 表示当peers数组中server都失败，不能提供服务了，通过upstream->next，切换到back数组中选择server.
2.2 具体的RR策略
2.2.1 ） 选择最初要轮循的server, 把它给rrp->current变量，跳转到2.2.2
当一个客户端请求到达nginx后，nginx就会在upstream的peers 数组中挑选一个current_weight最大的server作为当前请求最初要轮循的server. 在peers数组中选取current_weight最大的算法如下：
由于peers数组中的server是按照weight值的大小排序好的。
它是通过双重循环，满足下列条件后,
if (peer[n].current_weight * 1000 /peer[i].current_weight > peer[n].weight * 1000 / peer[i].weight) //peer[i].current_weight不为0
并且该server的current_weight大于0，就选择sever n, 把编号n赋给rrp->current，成功返回。
如果当upstream的peers 数组中的所有server的current_weight都为零时，立即无条件地把所有server的current_weight设置为初始值。for (i = 0; i < peers->number; i++) {
peer[i].current_weight =peer[i].weight;
}
然后，当所有server的current_weight设置为初始值后，重新查找peers 数组中current_weight最大的server。把编号赋给rrp->current，返回。
2.2.2 判断当前rrp->current所指向的server是否有效，如果无效，就会让rrp->current++，判断peers数组中下一个server，是否有效。至到找到有效的server为止. 跳转到2.2.3; 否则跳转到2.2.2.1
判断server是否有效的方法是：
1）如果server的失败次数（peers->peer[i].fails）没有达到了max_fails所设置的最大失败次数，则该server是有效的。
2）如果server已经达到了max_fails所设置的最大失败次数，从这一时刻开始算起，在fail_timeout 所设置的时间段内，server是无效的。
3）当server的失败次数（peers->peer[i].fails）为最大的失败次数，当距离现在的时间超过了fail_timeout所设置的时间段， 则令peers->peer[i].fails=0，使得该server重新有效。
2.2.2.1如果peers中所有的server都是无效的; 就会尝试去backup的数组中找一个有效的server, 如果找到， 跳转到2.2.3; 如果仍然找不到，表示此时upstream中无server可以使用。就会清空所有peers数组中所有的失败次数的记录，使所有server都变成了有效。这样做的目的是为了防止下次再有请求访问时，仍找不到一个有效的server.
for (i = 0; i <peers->number; i++) {
peers->peer[i].fails = 0;
}
并返回错误码给nginx, nginx得到此错误码后，就不再向后台server发请求，而是在nginx的错误日志中输出“no live upstreams while connecting to upstream”的记录（这就是no live产生的真正原因），并直接返回给请求的客户端一个502的错误。
2.2.3 当找到一个有效的server后，令该server的current_weight减一，然后，nginx就会尝试与该server建立连接。如果成功建立连接，跳转到2.2.4; 否则 跳转到2.2..3.1
2.2..3.1 如果nginx在等待了proxy_connect_timeout所设置的时间段后（如3秒），连接仍然没有建立成功，nginx就在错误日志中输出“upstreamtimed out (110: Connection timed out) while connecting to upstream”的记录（这就是 timedout（连接超时）产生的真正原因）.
2.2.3 .2 接着，让当前server的失败次数加一（peer->fails++; 如果该server最大失败次达到最大失败次数，将在一段时间内该server是无效的），如果当前nginx与后台服务器的尝试次数没有达到upstream中server的总个数，重新跳转到2.2.2, 轮循下一个server,继续尝试。如果达到最大尝试次数，就表示uptream中所有的server都尝试了一遍，没有server可以提供服务，返回一个504的错误给客户端。
2.2.4 当nginx与server建立连接成功后，如果server响应请求，把处理结果返回给nginx,
跳转到2.2.5; 否则跳转到2.2.4.1
2.2.4.1 如果nginx在等待了proxy_read_timeout所设置的时间段后（如30秒），server仍然没有对nginx发送来的请求作出响应，nginx就在错误日志中输出“upstreamtimed out (110: Connection timed out) while reading response headerfrom upstream”的记录（这就是 timed out（读超时）产生的真正原因）.
2.2.4.2 接着，让当前server的失败次数加一（peer->fails++; 如果该server最大失败次达到最大失败次数，将在一段时间内该server是无效的），如果当前nginx与后台服务器的尝试次数没有达到upstream中server的总个数，重新跳转到2.2.2, 轮循下一个server,继续尝试。如果达到最大尝试次数，就表示uptream中所有的server都尝试了一遍，没有server可以提供服务，返回一个504的错误给客户端。
2.2.5 Nginx收到后台server传送过来的结果后，就会返回给客户端一个200的正确结果。这样，nginx作为反向代理的功能也就完成了。
三、Ip_hash策略
3.1Ip_hash和RR 的策略有两点不同在于：
当一个客户请求到nginx后，
1）nginx如何选择一个最初的server,
2）以及当前选择的server不能提供服务时，如何选择下一个server.
3.2 RR策略回顾
从第二部分对RR的介绍中，我们知道：
当一个客户请求到达后，RR策略是从upstream的所有server中选择一个当前权重（current_weight）最大的server作为最初的server.
upstream的所有server是按照由高到低排序后存储在一个peers数组中，当最初选择的server不能提供服务时，RR策略就会选择peers数组中的下一个元素作为当前server，继续尝试， 如果已经达到数组的最大元素，就会从第一个元素再轮循。
3.3 ip_hash策略介绍
在ip_hash策略中，它选择最初的server的方法是根据请求客户端的IP计算出一个哈希值，再根据哈希值选择后台的服务器。
1）由IP计算哈希值的算法如下， 其中公式中hash初始值为89，iphp->addr[i]表示客户端的IP， 通过三次哈希计算得出一个IP的哈希值：
for (i = 0; i < 3;i++) {
hash = (hash* 113 + iphp->addr[i]) % 6271;
}
2）在选择下一个server时，ip_hash的选择策略是这样的：
它在上一次哈希值的基础上，再次哈希，就会得到一个全新的哈希值，再根据哈希值选择另外一个后台的服务器。
哈希算法仍然是
for (i = 0; i < 3;i++) {
hash = (hash * 113 +iphp->addr[i]) % 6271;
}
在这种ip_hash策略，如果一个后台服务器不能提供提服务（连接超时或读超时），该服务器的失败次数就会加一，当一个服务器的失败次数达到max_fails所设置的值，就会在fail_timeout所设置的时间段内不能对外提供服务，这点和RR是一致的。
如果当前server不能提供服务，就会根据当前的哈希值再哈希出一个新哈希值，选择另一个服务器继续尝试，尝试的最大次是upstream中server的个数，如果server的个数超过20，也就是要最大尝试次数在20次以上，当尝试次数达到20次，仍然找不到一个合适的服务器，ip_hah策略不再尝试ip哈希值来选择server, 而在剩余的尝试中，它会转而使用RR的策略，使用轮循的方法，选择新的server。
3）除了以上部分不同外，IP_hash的其余部分和RR完全一样，因为它的其余部分功能的实现都是通过调用RR中的函数。
4）IP_hash优势是把同一个客户IP的请求分配给同一个后台服务器。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
