還是沒有經驗啊！面對一個高並發的秒殺活動。最終統計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