邢栋博客
邢栋博客，Action博客，记录工作和生活中的点点滴滴
nginx中fastcgi_param参数说明
fastcgi_param QUERY_STRING $query_string; #请求的参数;如?app=123
fastcgi_param REQUEST_METHOD $request_method; #请求的动作(GET,POST)
fastcgi_param CONTENT_TYPE $content_type; #请求头中的Content-Type字段
fastcgi_param CONTENT_LENGTH $content_length; #请求头中的Content-length字段。
fastcgi_param SCRIPT_NAME $fastcgi_script_name; #脚本名称
fastcgi_param REQUEST_URI $request_uri; #请求的地址不带参数
fastcgi_param DOCUMENT_URI $document_uri; #与$uri相同。
fastcgi_param DOCUMENT_ROOT $document_root; #网站的根目录。在server配置中root指令中指定的值
fastcgi_param SERVER_PROTOCOL $server_protocol; #请求使用的协议，通常是HTTP/1.0或HTTP/1.1
fastcgi_param REQUEST_SCHEME $scheme;
fastcgi_param HTTPS $https if_not_empty;
fastcgi_param GATEWAY_INTERFACE CGI/1.1; #cgi 版本
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; #nginx 版本号，可修改、隐藏
fastcgi_param REMOTE_ADDR $remote_addr; #客户端IP
fastcgi_param REMOTE_PORT $remote_port; #客户端端口
fastcgi_param SERVER_ADDR $server_addr; #服务器IP地址
fastcgi_param SERVER_PORT $server_port; #服务器端口
fastcgi_param SERVER_NAME $server_name; #服务器名，域名在server配置中指定的server_name
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
fastcgi_param REQUEST_METHOD $request_method; #请求的动作(GET,POST)
fastcgi_param CONTENT_TYPE $content_type; #请求头中的Content-Type字段
fastcgi_param CONTENT_LENGTH $content_length; #请求头中的Content-length字段。
fastcgi_param SCRIPT_NAME $fastcgi_script_name; #脚本名称
fastcgi_param REQUEST_URI $request_uri; #请求的地址不带参数
fastcgi_param DOCUMENT_URI $document_uri; #与$uri相同。
fastcgi_param DOCUMENT_ROOT $document_root; #网站的根目录。在server配置中root指令中指定的值
fastcgi_param SERVER_PROTOCOL $server_protocol; #请求使用的协议，通常是HTTP/1.0或HTTP/1.1
fastcgi_param REQUEST_SCHEME $scheme;
fastcgi_param HTTPS $https if_not_empty;
fastcgi_param GATEWAY_INTERFACE CGI/1.1; #cgi 版本
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version; #nginx 版本号，可修改、隐藏
fastcgi_param REMOTE_ADDR $remote_addr; #客户端IP
fastcgi_param REMOTE_PORT $remote_port; #客户端端口
fastcgi_param SERVER_ADDR $server_addr; #服务器IP地址
fastcgi_param SERVER_PORT $server_port; #服务器端口
fastcgi_param SERVER_NAME $server_name; #服务器名，域名在server配置中指定的server_name
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;
nginx负载均衡 - 根据url做一致性hash
nginx负载均衡 - 根据url做一致性hash
目标:按照指定的参数(如分类/商品编号)做一致性hash，从而保证相同数据到一台机器上
先说下nginx里$request_uri和$uri的区别
$request_uri
This variable is equal to the *original* request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI. Does not include host name. Example: "/foo/bar.php?arg=baz"
这个变量等于从客户端发送来的原生请求URI，包括参数。它不可以进行修改。$uri变量反映的是重写后/改变的URI。不包括主机名。例如："/foo/bar.php?arg=baz"
$uri
This variable is the current request URI, without any arguments (see $args for those). This variable will reflect any modifications done so far by internal redirects or the index module. Note this may be different from $request_uri, as $request_uri is what was originally sent by the browser before any such modifications. Does not include the protocol or host name. Example: /foo/bar.html
这个变量指当前的请求URI，不包括任何参数(见$args)。这个变量反映任何内部重定向或index模块所做的修改。注意，这和$request_uri不同，因$request_uri是浏览器发起的不做任何修改的原生URI。不包括协议及主机名。例如："/foo/bar.html"
$document_uri
The same as $uri.
同$uri.
实现步骤
第一步:在nginx中做简单配置,先实现轮训,域名可以根据自己的来
server {
listen 80;
server_name default www.test.com;
location / {
proxy_pass http://www_posts;
index index.html index.htm;
}
}
upstream www_posts {
server 127.0.0.1:7001;
server 127.0.0.1:7002;
server 127.0.0.1:7003;
}
server {
listen 7001;
server_name default www.test.com;
location / {
root /data/www/post1/;
index index.html index.htm;
}
}
server {
listen 7002;
server_name default www.test.com;
location / {
root /data/www/post2/;
index index.html index.htm;
}
}
server {
listen 7003;
server_name default www.test.com;
location / {
root /data/www/post3/;
index index.html index.htm;
}
}
完成后 重启nginx
第二步创建程序文件
mkdir /data/www/post1; cd /data/www/post1;
vim 1.html //写入 1-1
vim 2.html //写入 1-2
vim 3.html //写入 1-3
mkdir /data/www/post2; cd /data/www/post2;
vim 1.html //写入 2-1
vim 2.html //写入 2-2
vim 3.html //写入 2-3
mkdir /data/www/post3; cd /data/www/post3;
vim 1.html //写入 3-1
vim 2.html //写入 4-2
vim 3.html //写入 3-3
通过浏览器访问 www.test.com/1.html，不断刷新，可分别出现1-1,2-1,3-1
第三步 自定义hash key
在server-location中加入
if ( $uri ~* "^\/(\d+).html$" ){ set $defurlkey $1; }
修改upstream，结果如下
upstream www_posts {
hash $defurlkey;
server 127.0.0.1:7001;
server 127.0.0.1:7002;
server 127.0.0.1:7003;
}
可通过分别访问,测试结果
www.test.com/1.html
www.test.com/2.html
www.test.com/3.html
目标:按照指定的参数(如分类/商品编号)做一致性hash，从而保证相同数据到一台机器上
先说下nginx里$request_uri和$uri的区别
$request_uri
This variable is equal to the *original* request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI. Does not include host name. Example: "/foo/bar.php?arg=baz"
这个变量等于从客户端发送来的原生请求URI，包括参数。它不可以进行修改。$uri变量反映的是重写后/改变的URI。不包括主机名。例如："/foo/bar.php?arg=baz"
$uri
This variable is the current request URI, without any arguments (see $args for those). This variable will reflect any modifications done so far by internal redirects or the index module. Note this may be different from $request_uri, as $request_uri is what was originally sent by the browser before any such modifications. Does not include the protocol or host name. Example: /foo/bar.html
这个变量指当前的请求URI，不包括任何参数(见$args)。这个变量反映任何内部重定向或index模块所做的修改。注意，这和$request_uri不同，因$request_uri是浏览器发起的不做任何修改的原生URI。不包括协议及主机名。例如："/foo/bar.html"
$document_uri
The same as $uri.
同$uri.
实现步骤
第一步:在nginx中做简单配置,先实现轮训,域名可以根据自己的来
server {
listen 80;
server_name default www.test.com;
location / {
proxy_pass http://www_posts;
index index.html index.htm;
}
}
upstream www_posts {
server 127.0.0.1:7001;
server 127.0.0.1:7002;
server 127.0.0.1:7003;
}
server {
listen 7001;
server_name default www.test.com;
location / {
root /data/www/post1/;
index index.html index.htm;
}
}
server {
listen 7002;
server_name default www.test.com;
location / {
root /data/www/post2/;
index index.html index.htm;
}
}
server {
listen 7003;
server_name default www.test.com;
location / {
root /data/www/post3/;
index index.html index.htm;
}
}
完成后 重启nginx
第二步创建程序文件
mkdir /data/www/post1; cd /data/www/post1;
vim 1.html //写入 1-1
vim 2.html //写入 1-2
vim 3.html //写入 1-3
mkdir /data/www/post2; cd /data/www/post2;
vim 1.html //写入 2-1
vim 2.html //写入 2-2
vim 3.html //写入 2-3
mkdir /data/www/post3; cd /data/www/post3;
vim 1.html //写入 3-1
vim 2.html //写入 4-2
vim 3.html //写入 3-3
通过浏览器访问 www.test.com/1.html，不断刷新，可分别出现1-1,2-1,3-1
第三步 自定义hash key
在server-location中加入
if ( $uri ~* "^\/(\d+).html$" ){ set $defurlkey $1; }
修改upstream，结果如下
upstream www_posts {
hash $defurlkey;
server 127.0.0.1:7001;
server 127.0.0.1:7002;
server 127.0.0.1:7003;
}
可通过分别访问,测试结果
www.test.com/1.html
www.test.com/2.html
www.test.com/3.html
nginx限制某个IP同一时间段的访问次数(转)
坑说明
公司内有好几个网段，测试那边在测试的时候偶尔会出现503，我这边切换了几个网，有的可以正常访问范围，有的是出现503，访问html文件也是如此,最后查看服务器的nginx配置,发现了一些参数，原来是nginx限制某个IP同一时间段的访问次数
相关资料
HttpLimitReqModul用来限制连单位时间内连接数的模块，使用limit_req_zone和limit_req指令配合使用来达到限制。一旦并发连接超过指定数量，就会返回503错误。
HttpLimitConnModul用来限制单个ip的并发连接数，使用limit_zone和limit_conn指令
这两个模块的区别前一个是对一段时间内的连接数限制，后者是对同一时刻的连接数限制
HttpLimitReqModul 限制某一段时间内同一ip访问数实例
limit_zone只能定义在http作用域，limit_conn可以定义在http server location作用域
nginx白名单设置
以上配置会对所有的ip都进行限制，有些时候我们不希望对搜索引擎的蜘蛛或者自己测试ip进行限制，
对于特定的白名单ip我们可以借助geo指令实现。
geo指令定义了一个白名单$limited变量，默认值为1，如果客户端ip在上面的范围内，$limited的值为0
2.使用map指令映射搜索引擎客户端的ip为空串，如果不是搜索引擎就显示本身真是的ip，这样搜索引擎ip就不能存到limit_req_zone内存session中，所以不会限制搜索引擎的ip访问
map $limited $limit {
1 $binary_remote_addr;
0 "";
}
3.设置limit_req_zone和limit_req
limit_req_zone $limit zone=foo:1m rate=10r/m;
limit_req zone=foo burst=5;
最后我们使用ab压php-fpm的方式，对上面的方法效果实际测试下
例1：限制只允许一分钟内只允许一个ip访问60次配置，也就是平均每秒1次
首先我们准备一个PHP脚本放在根目录下$document_root
test.php
for( $i=0; $i < 1000; $i++)
echo 'Hello World';
?>
nginx配置增加limit_req_zone 和 limit_req
ab -n 5 -c 1 http://www.weizhang.org/test.php
118.144.94.193 - - [22/Dec/2012:06:27:06 +0000] "GET /test.php HTTP/1.0" 200 11000 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:06 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:07 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:07 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:07 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
未设置brust和nodelay可以看到该配置只允许每秒访问1次，超出的请求返回503错误
ab -n 5 -c 1 http://www.weizhang.org/test.php
118.144.94.193 - - [22/Dec/2012:07:01:00 +0000] "GET /test.php HTTP/1.0" 200 11000 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:00 +0000] "GET /test.php HTTP/1.0" 200 11000 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:01 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:01 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
原文地址:http://blog.csdn.net/gebitan505/article/details/17610485
公司内有好几个网段，测试那边在测试的时候偶尔会出现503，我这边切换了几个网，有的可以正常访问范围，有的是出现503，访问html文件也是如此,最后查看服务器的nginx配置,发现了一些参数，原来是nginx限制某个IP同一时间段的访问次数
相关资料
HttpLimitReqModul用来限制连单位时间内连接数的模块，使用limit_req_zone和limit_req指令配合使用来达到限制。一旦并发连接超过指定数量，就会返回503错误。
HttpLimitConnModul用来限制单个ip的并发连接数，使用limit_zone和limit_conn指令
这两个模块的区别前一个是对一段时间内的连接数限制，后者是对同一时刻的连接数限制
HttpLimitReqModul 限制某一段时间内同一ip访问数实例
http{
...
#定义一个名为allips的limit_req_zone用来存储session，大小是10M内存，
#以$binary_remote_addr 为key,限制平均每秒的请求为20个，
#1M能存储16000个状态，rete的值必须为整数，
#如果限制两秒钟一个请求，可以设置成30r/m
limit_req_zone $binary_remote_addr zone=allips:10m rate=20r/s;
...
server{
...
location {
...
#限制每ip每秒不超过20个请求，漏桶数burst为5
#brust的意思就是，如果第1秒、2,3,4秒请求为19个，
#第5秒的请求为25个是被允许的。
#但是如果你第1秒就25个请求，第2秒超过20的请求返回503错误。
#nodelay，如果不设置该选项，严格使用平均速率限制请求数，
#第1秒25个请求时，5个请求放到第2秒执行，
#设置nodelay，25个请求将在第1秒执行。
limit_req zone=allips burst=5 nodelay;
...
}
...
}
...
}
HttpLimitZoneModule 限制并发连接数实例limit_zone只能定义在http作用域，limit_conn可以定义在http server location作用域
http{
...
#定义一个名为one的limit_zone,大小10M内存来存储session，
#以$binary_remote_addr 为key
#nginx 1.18以后用limit_conn_zone替换了limit_conn
#且只能放在http作用域
limit_conn_zone one $binary_remote_addr 10m;
...
server{
...
location {
...
limit_conn one 20; #连接数限制
#带宽限制,对单个连接限数，如果一个ip两个连接，就是500x2k
limit_rate 500k;
...
}
...
}
...
}
nginx白名单设置
以上配置会对所有的ip都进行限制，有些时候我们不希望对搜索引擎的蜘蛛或者自己测试ip进行限制，
对于特定的白名单ip我们可以借助geo指令实现。
http{
geo $limited{
default 1;
#google
64.233.160.0/19 0;
65.52.0.0/14 0;
66.102.0.0/20 0;
66.249.64.0/19 0;
72.14.192.0/18 0;
74.125.0.0/16 0;
209.85.128.0/17 0;
216.239.32.0/19 0;
#M$
64.4.0.0/18 0;
157.60.0.0/16 0;
157.54.0.0/15 0;
157.56.0.0/14 0;
207.46.0.0/16 0;
207.68.192.0/20 0;
207.68.128.0/18 0;
#yahoo
8.12.144.0/24 0;
66.196.64.0/18 0;
66.228.160.0/19 0;
67.195.0.0/16 0;
74.6.0.0/16 0;
68.142.192.0/18 0;
72.30.0.0/16 0;
209.191.64.0/18 0;
#My IPs
127.0.0.1/32 0;
123.456.0.0/28 0; #example for your server CIDR
}
geo指令定义了一个白名单$limited变量，默认值为1，如果客户端ip在上面的范围内，$limited的值为0
2.使用map指令映射搜索引擎客户端的ip为空串，如果不是搜索引擎就显示本身真是的ip，这样搜索引擎ip就不能存到limit_req_zone内存session中，所以不会限制搜索引擎的ip访问
map $limited $limit {
1 $binary_remote_addr;
0 "";
}
3.设置limit_req_zone和limit_req
limit_req_zone $limit zone=foo:1m rate=10r/m;
limit_req zone=foo burst=5;
最后我们使用ab压php-fpm的方式，对上面的方法效果实际测试下
例1：限制只允许一分钟内只允许一个ip访问60次配置，也就是平均每秒1次
首先我们准备一个PHP脚本放在根目录下$document_root
test.php
for( $i=0; $i < 1000; $i++)
echo 'Hello World';
?>
nginx配置增加limit_req_zone 和 limit_req
http{
...
limit_req_zone $binary_remote_addr zone=allips:10m rate=60r/m;
...
server{
...
location {
...
limit_req zone=allips;
...
}
...
}
...
}
ab -n 5 -c 1 http://www.weizhang.org/test.php
118.144.94.193 - - [22/Dec/2012:06:27:06 +0000] "GET /test.php HTTP/1.0" 200 11000 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:06 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:07 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:07 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:06:27:07 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
未设置brust和nodelay可以看到该配置只允许每秒访问1次，超出的请求返回503错误
http{
...
limit_req_zone $binary_remote_addr zone=allips:10m rate=60r/m;
...
server{
...
location {
...
limit_req zone=allips burst=1 nodelay;
...
}
...
}
...
}
ab -n 5 -c 1 http://www.weizhang.org/test.php
118.144.94.193 - - [22/Dec/2012:07:01:00 +0000] "GET /test.php HTTP/1.0" 200 11000 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:00 +0000] "GET /test.php HTTP/1.0" 200 11000 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:01 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:01 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
118.144.94.193 - - [22/Dec/2012:07:01:01 +0000] "GET /test.php HTTP/1.0" 503 537 "-" "ApacheBench/2.3"
设置brust=1和nodelay后允许第1秒处理两个请求。原文地址:http://blog.csdn.net/gebitan505/article/details/17610485
关于nginx启动、停止、重启命令总结
标签:
nginx
nginx启动
/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
nginx停止
1.从容停止
ps aux|grep nginx //master进程号,例如是 1480
kill -QUIT 1480
2.快速停止
kill -TERM 1480 或 kill INT 1480
3.强制停止
pkill -9 nginx 或 killall nginx
nginx重启
检测配置文件是否正确
nginx -t
然后
nginx -s reload 或者 kill -HUP 1480
关于nginx的master和worker进程模型
标签:
nginx
关于nginx的master和worker进程模型
正常执行中的nginx会有多个进程，最基本的有master process（监控进程，也叫做主进程）和woker process（工作进程），还可能有cache相关进程。
master进程
监控进程充当整个进程组与用户的交互接口，同时对进程进行监护。它不需要处理网络事件，不负责业务的执行，只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
worker进程
worker进程的主要任务是完成具体的任务逻辑。其主要关注点是与客户端或后端真实服务器（此时nginx作为中间代理）之间的数据可读/可写等I/O交互事件，所以工作进程的阻塞点是在像select()、epoll_wait()等这样的I/O多路复用函数调用处，以等待发生数据可读/写事件。当然也可能被新收到的进程信号中断。
原文具体链接:http://www.tuicool.com/articles/NNZvquV
nginx访问ci框架出现Access denied.
nginx访问ci框架出现Access denied.
nginx访问ci框架出现Access denied.
Lepus(天兔)web管理台nginx重写
server {
listen 80;
server_name lepus.example.com;
client_max_body_size 10m;
index index.html index.htm index.php;
root /work/www/lepus;
fastcgi_intercept_errors on;
location / {
root /work/www/lepus;
index index.html index.htm index.php;
#rewrite规则如下：
rewrite ^(.*)$ /index.php?s=$1 last;
}
location ~ ^(.+\.php)(.*)$ {
root /work/www/lepus;
fastcgi_index index.php;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
#注意：去临时文件夹内找到你的php-cgi，也可能php-cgi.sock不是这么个名字。
fastcgi_pass unix:/dev/shm/php-cgi.sock;
include fastcgi_params;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
expires 30d;
}
location ~ .*\.(js|css)?$ {
expires 1h;
}
}
修改php.ini配置文件
cgi.fix_pathinfo=1
nginx访问ci框架出现Access denied.
Lepus(天兔)web管理台nginx重写
server {
listen 80;
server_name lepus.example.com;
client_max_body_size 10m;
index index.html index.htm index.php;
root /work/www/lepus;
fastcgi_intercept_errors on;
location / {
root /work/www/lepus;
index index.html index.htm index.php;
#rewrite规则如下：
rewrite ^(.*)$ /index.php?s=$1 last;
}
location ~ ^(.+\.php)(.*)$ {
root /work/www/lepus;
fastcgi_index index.php;
fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
#注意：去临时文件夹内找到你的php-cgi，也可能php-cgi.sock不是这么个名字。
fastcgi_pass unix:/dev/shm/php-cgi.sock;
include fastcgi_params;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
expires 30d;
}
location ~ .*\.(js|css)?$ {
expires 1h;
}
}
修改php.ini配置文件
cgi.fix_pathinfo=1
Nginx/LVS/HAProxy负载均衡软件的优缺点详解(转)
(总结）Nginx/LVS/HAProxy负载均衡软件的优缺点详解
一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。
一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。
目前关于网站架构一般比较合理流行的架构方案：Web前端采用Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。
下面说说各自的特点和适用场合。
一、Nginx
Nginx的优点是：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。
2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会；
3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。
3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。
4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。
5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。
7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
8、Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。
Nginx的缺点是：
1、Nginx仅能支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点。
2、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。不支持Session的直接保持，但能通过ip_hash来解决。
二、LVS
LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。
LVS的优点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。
2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。
4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会收到大流量的影响。
5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。
LVS的缺点是：
1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
三、HAProxy
HAProxy的特点是：
1、HAProxy也是支持虚拟主机的。
2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。
3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。
5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种：
① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
② static-rr，表示根据权重，建议关注；
③ leastconn，表示最少连接者先处理，建议关注；
④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
⑤ ri，表示根据请求的URI；
⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；
⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。
四、总结
Nginx和LVS对比的总结：
1、Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所以Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，触碰多了，人为出问题的几率也就会大。
2、Nginx对网络稳定性的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，这是Nginx的一大优势！Nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。
3、Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了；LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的。
5、Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，apache上就不会堆积过多的请求，这样就减少了相当多的资源占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。
7、Nginx能支持http、https和email（email的功能比较少用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析，如果是比较小的网站（日PV小于1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS。
现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
第一阶段：利用Nginx或HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。这时是第一选择。
第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用Array就是首要选择，Nginx此时就作为LVS或者Array的节点来使用，具体LVS或Array的是选择是根据公司规模和预算来选择，Array的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于F5，商用首选！但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。
最终形成比较理想的基本架构为：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。
原文地址 http://www.ha97.com/5646.html
一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析，如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以了；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。
一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。
目前关于网站架构一般比较合理流行的架构方案：Web前端采用Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。当然要根据项目具体需求制定方案。
下面说说各自的特点和适用场合。
一、Nginx
Nginx的优点是：
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是它目前广泛流行的主要原因之一，Nginx单凭这点可利用的场合就远多于LVS了。
2、Nginx对网络稳定性的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势之一；相反LVS对网络稳定性依赖比较大，这点本人深有体会；
3、Nginx安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。LVS的配置、测试就要花比较长的时间了，LVS对网络依赖比较大。
3、可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS相对小些。
4、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。
5、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP也是近几年非常流行的web架构，在高流量的环境中稳定性也很好。
6、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，可以考虑用其作为反向代理加速器。
7、Nginx可作为中层反向代理使用，这一层面Nginx基本上无对手，唯一可以对比Nginx的就只有lighttpd了，不过lighttpd目前还没有做到Nginx完全的功能，配置也不那么清晰易读，社区资料也远远没Nginx活跃。
8、Nginx也可作为静态网页和图片服务器，这方面的性能也无对手。还有Nginx社区非常活跃，第三方模块也很多。
Nginx的缺点是：
1、Nginx仅能支持http、https和Email协议，这样就在适用范围上面小些，这个是它的缺点。
2、对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测。不支持Session的直接保持，但能通过ip_hash来解决。
二、LVS
LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。
LVS的优点是：
1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。
2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。
4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会收到大流量的影响。
5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。
LVS的缺点是：
1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。
三、HAProxy
HAProxy的特点是：
1、HAProxy也是支持虚拟主机的。
2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。
3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。
5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种：
① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
② static-rr，表示根据权重，建议关注；
③ leastconn，表示最少连接者先处理，建议关注；
④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
⑤ ri，表示根据请求的URI；
⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；
⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。
四、总结
Nginx和LVS对比的总结：
1、Nginx工作在网络的7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下LVS并不具备这样的功能，所以Nginx单凭这点可利用的场合就远多于LVS了；但Nginx有用的这些功能使其可调整度要高于LVS，所以经常要去触碰触碰，触碰多了，人为出问题的几率也就会大。
2、Nginx对网络稳定性的依赖较小，理论上只要ping得通，网页访问正常，Nginx就能连得通，这是Nginx的一大优势！Nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；LVS就比较依赖于网络环境，目前来看服务器在同一网段内并且LVS使用direct方式分流，效果较能得到保证。另外注意，LVS需要向托管商至少申请多一个ip来做Visual IP，貌似是不能用本身的IP来做VIP的。要做好LVS管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个HTTP那么简单了。
3、Nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。LVS的安装和配置、测试就要花比较长的时间了；LVS对网络依赖比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4、Nginx也同样能承受很高负载且稳定，但负载度和稳定度差LVS还有几个等级：Nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的。
5、Nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前LVS中 ldirectd也能支持针对服务器内部的情况来监控，但LVS的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载，假如使用apache直接对外服务，那么出现很多的窄带链接时apache服务器将会占用大 量内存而不能释放，使用多一个Nginx做apache代理的话，这些窄带链接会被Nginx挡住，apache上就不会堆积过多的请求，这样就减少了相当多的资源占用。这点使用squid也有相同的作用，即使squid本身配置为不缓存，对apache还是有很大帮助的。
7、Nginx能支持http、https和email（email的功能比较少用），LVS所支持的应用在这点上会比Nginx更多。在使用上，一般最前端所采取的策略应是LVS，也就是DNS的指向应为LVS均衡器，LVS的优点令它非常适合做这个任务。重要的ip地址，最好交由LVS托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 LVS托管是最为稳妥的，这样做的唯一缺点是需要的VIP数量会比较多。Nginx可作为LVS节点机器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。当然这一层面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所逊色于Nginx。Nginx也可作为中层代理使用，这一层面Nginx基本上无对手，唯一可以撼动Nginx的就只有lighttpd了，不过lighttpd目前还没有能做到 Nginx完全的功能，配置也不那么清晰易读。另外，中层代理的IP也是重要的，所以中层代理也拥有一个VIP和LVS是最完美的方案了。具体的应用还得具体分析，如果是比较小的网站（日PV小于1000万），用Nginx就完全可以了，如果机器也不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用LVS。
现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
第一阶段：利用Nginx或HAProxy进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx或HAproxy就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用HTTP协议就可以。这时是第一选择。
第二阶段：随着网络服务进一步扩大，这时单点的Nginx已经不能满足，这时使用LVS或者商用Array就是首要选择，Nginx此时就作为LVS或者Array的节点来使用，具体LVS或Array的是选择是根据公司规模和预算来选择，Array的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于F5，商用首选！但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。
第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的LVS，已经成为首选，这时LVS会成为主流。
最终形成比较理想的基本架构为：Array/LVS — Nginx/Haproxy — Squid/Varnish — AppServer。
原文地址 http://www.ha97.com/5646.html
