高并发下的服务器配置与优化（nginx限流方案）

 还是没有经验啊！面对一个高并发的秒杀活动。最终统计24小时内有

300多万的PV   和 30多万的UV

 在活动开始之前，这边写了一个入口的数据统计（相当于每点击一次入口页面，就增加一次PV，再统计下UV ），然后每隔五分钟进行一次统计（统计PV和UV的增长量和总量）

(‾◡◝) 一开始还是很自信的，毕竟都是每分钟几百个的访问量。对于三台高配的服务器来说完全木有压力；

知道开抢的前十分钟(ﾟｰﾟ)   访问量由1000/Min  飙到 12000/Min.....  What???the F？

然后不出意外地服务器蹦了！！一个小时内的负载均衡服务器的errLog 达到了1Gib的容量(。﹏。*)

——————追溯到一开始之前的准备工作————————

三台服务器：8核64gib内存和足够的硬盘空间；其中一台服务器作为Nginx负载均衡服务器，用户分发流量给另外两台服务器

代码逻辑处理：使用redis作为主要的数据缓存，用于请求的快速接收和存储。减少对数据库的IO。然后通过队列的模式在一个个写入数据库；//事实证明。内存作为数据的临时存储是非常有效的。cpu的消耗始终没有超过10%；

文件描述符：ulimit -n 可以查看当前可使用的数量，默认是1024；

购买使用CDN加速，将前端的静态文件放置在CDN上，非常有效的减少带宽压力。你算算如果100k的js+css文件 乘以几万的请求，可想而知，服务器的宽带远远不足。

以下附上几个文件描述符常用的命令

//查看当前 系统正在打开的描述符
cat /proc/sys/fs/file-nr

//注意 最大描述符不能超过
cat /proc/sys/fs/nr_open

//修改资源符
sudo vim /etc/security/limits.conf

>在后面加上这两句 soft是警告值，hard是极限值

* soft nofile 65535
* hard nofile 65535

nginx.conf的配置：
worker_processes 16  #这个根据cpu核数来限制

worker_connections 65535 #这个不加的话默认是1024个网络连接，高并发的情况下，就会报错

http{

large_client_header_buffers 4 16k;
client_body_buffer_size 128k;

proxy_connect_timeout 300;
proxy_read_timeout 300;
proxy_send_timeout 300;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

client_max_body_size 100M;

keepalive_timeout 65;

proxy_headers_hash_max_size 51200;
proxy_headers_hash_bucket_size 6400;

include /etc/nginx/conf.d/*.conf;

}

proxy.conf的配置

upstream backend {
server ip1;
server ip2;
}

limit_req_zone $binary_remote_addr zone=mylimit:20m rate=1r/s;   #这里做了限流处理 意思是开启mylimit的zone ，这里限制的是1次/秒（单个ip），如果超过这个限制，会被拒绝请求

server {
listen 80;#监听80端口
listen 443 ssl;#监听443 https的端口
server_name localhost;#域名

//这里配置https签名
#ssl on;#这个要关掉，避免https请求转发到http请求，因为upstream 指定的两台服务器，允许http请求

#下面这块是标准的https配置
ssl_certificate /etc/nginx/conf.d/cert/localhost.crt;
ssl_certificate_key /etc/nginx/conf.d/cert/localhost.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
ssl_prefer_server_ciphers on;

#这块是指定/api/下所有的请求进行限流配置，limit_req_zone在此处生效

location /api/{
limit_req zone=mylimit burst=1000 nodelay;#这里限制了1000个并发，nodelay如果不设置的话，超过这个量的请求直接被拒绝访问，返回下面limit_req_status定义的状态
limit_req_status 503;#自定义返回状态
add_header X-Content-Type-Options nosniff;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_hide_header X-Powered-By;
proxy_hide_header Vary;
proxy_pass http://backend;
proxy_redirect off;
}

#这款不做限流限制，访问api的会走上面，除了api的我这个项目基本都是静态页面，所以不需要做限流操作
location / {
add_header X-Content-Type-Options nosniff;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_hide_header X-Powered-By;
proxy_hide_header Vary;
proxy_pass http://backend;
proxy_redirect off;
}

}

顾名思义。限流的作用是用于减少单位时间的请求量。在用户的体验角度来说，就会差很多；

Akin推荐一篇nginx限流相关文章，写的很通俗易懂：https://www.cnblogs.com/biglittleant/p/8979915.html