nginx如何实现高并发？

启动nginx服务器后,输入 ps -ef |grep nginx,会发现nginx有一个master进程 和若干个worker进程,

这些worker进程是平等的,都是被master fork 过来的,在master里面,先建立需要listen 的 socket(listenfd)，

然后再fork出多个worker进程.当用户进入nginx服务的时候,每个worker的listenfd 变的可读,并且这些worker

会抢一个叫accept_mutex的东西,accept_mutex 是互斥的,一个worker得到了,其他的worker 就歇菜了.

而抢到这个accept_mutex 的worker就开始 读取请求--解析请求--处理请求--返回数据给 客户端后,这个事件就算彻底结束

nginx 用这个方法是底下的worker进程抢注用户的要求,搭配 异步非阻塞的方式,实现高并发

nginx.conf 的第二行家是work_process 默认为4 也可以更改成 auto 这个值不是越大越好

编写一个 access模块 要求准许 192.168.3.29/24 的机器访问,准许10.1.20.6/16这个网段的所有机器访问,

准许34.26.157.0/24 这个网段访问,除此之外的机器不准许访问

location /{

access 192.168.3.29/24;

access 10.1.20.6/16;

access 34.26.157.0/24;

deny all;

}

nginx负载均衡用法

nginx 不能直接和java 搭配使用,因为nginx不能解析java,nginx一般指向java服务器,

nginx指向tomcat,tomcat 指向java

在http{} 这个括号里面有两个内置大括号 ,一个是 upstream xx{} ，一个是 server {  ...proxy_pass http://xx }

利用proxy_pass 这个属性同 upstream 进行交互,转移到tomcat 里面了

一个最简单的 upstream 写法如下

upstream backend{

　server backend1.example.com;

　server backend2.example.com;

　server.backend3.example.com

}

server{

　　　　location /{

　　　　　　proxy_pass http://backend

　　}

}

1后端服务器

通过upstream 可以设定后端服务器,指定的方式可以是IP 地址与端口,域名,unix套接字(socket)

其中如果域名可以被解析为多个地址,则这些地址都作为backend 

upsteam backend{

　　server blog.csdn.net/poechant;

　　server 145.223.156.89:8090;

　　server unix:/tmp/backend3;

}

第一个backend 是用域名指定的.第二个backend是用IP 和端口号指定的.第三个backend 是用unix套接字指定的

2、负载均衡策略

分为轮询（round robin）、用户 IP 哈希（client IP）和指定权重 3 种方式，默认情况下，提供轮询作为负载均衡策略。

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

这种策略中，用于进行 hash 运算的 key，是 client 的 C 类 IP 地址（C 类 IP 地址就是范围在 192.0.0.0 到 223.255.255.255 之间，前三段号码表示子网，第四段号码为本地主机的 IP 地址类别）。这样的方式保证一个 client 每次请求都将到达同一个 backend。当然，如果所 hash 到的 backend 当前不可用，则请求会被转移到其他 backend。

再介绍一个和 ip_hash 配合使用的关键字：down。当某个一个 server 暂时性的宕机（down）时，你可以使用“down”来标示出来，并且这样被标示的 server 就不会接受请求去处理。具体如下：

upstream backend {
    server blog.csdn.net/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

还可以使用指定权重（weight）的方式，如下：

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默认情况下 weight 为 1，对于上面的例子，第一个 server 的权重取默认值 1，第二个是 4，所以相当于第一个 server 接收 20% 的请求，第二接收 80% 的。要注意的是 weight 与 ip_hash 是不能同时使用的，原因很简单，他们是不同且彼此冲突的策略。

3、重试策略

可以为每个 backend 指定最大的重试次数，和重试时间间隔。所使用的关键字是 max_fails 和 fail_timeout。如下所示：

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中，最大失败次数为 3，也就是最多进行 3 次尝试，且超时时间为 30秒。max_fails 的默认值为 1，fail_timeout 的默认值是 10s。传输失败的情形，由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 响应时间。

有一种情况需要注意，就是 upstream 中只有一个 server 时，max_fails 和 fail_timeout 参数可能不会起作用。导致的问题就是只会尝试一次 upstream 请求，如果失败这个请求就被抛弃了 : ( ……解决的方法，比较取巧，就是在 upstream 中将你这个可怜的唯一 server 多写几次，如下：

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、备机策略

   可以使用“backup”关键字。当所有的非备机（non-backup）都宕机（down）或者繁忙（busy）的时候，就只使用由 backup 标注的备机。必须要注意的是，backup 不能和 ip_hash 关键字一起使用。举例如下：

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}

nginx常见错误处理方法

404 bad request

一般原因:请求的header过大

解决方法:配置的nginx.conf 相关设置

client_header_buffer_size 16k

large_client_header_buffer 4 64k

413 request Entity Too Large

一般原因:文件上传问题

解决方法: 配置nginx.conf 相关设置

1.client_max_body_size 10m;

配置php.ini 如下 必须和nginx.conf保持一致

post_max_size=10M

upload_max_filesize=2M

499 Client Closed Request

一般原因:客户端在未等到服务器相应返回前就关闭了客户端描述符

一般出现在客户端设置超时后,主动关闭SOCKET 解决方法:根据实际Nginx 后端服务器的处理时间修改客户端超时时间

500 Internal server error

一般原因;脚本错误(php语法错误,lua语法错误)

访问量过大,系统资源限制,不能打开过多的文件

 磁盘空间不足 (access_log 开启可能导致磁盘满溢 关闭)

解决方法:语法错误查看 nginx_err_log php_err_log

文件访问量

1.修改nginx 配置文件

1.worker_rlimit_nofile 65535

2 修改/etc/security/limits.conf

1. * soft nofile  65535

2. * hard nofile 65535

502 Bad GATEWAY 503 Service Unavailable

一般原因:后端服务无法处理,业务中断

解决方法:根据后端服务器实际处理情况,调正后请求超时时间

1.proxy_read_timeout 90;

2.proxy_send_timeout 90

一般原因:可能网站页面缓存大,而fastcgi默认进程应缓存区 8k

解决方法:配置nginx.conf 相关设置

1.fastcgi_buffers 8  128k

1.send_timeout 60

http://www.cnblogs.com/liyongsan/p/6795851.html

nginx 知识