还是没有经验啊!面对一个高并发的秒杀活动。最终统计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
本站文章如无特殊说明,均为本站原创,如若转载,请注明出处:高并发下的服务器配置与优化(nginx限流方案) - Python技术站