二. 緩存配置
1. 背景
分析一個電商網站的詳情頁面,如下圖,設計到很多微服務:商品詳情頁HTML頁面渲染、價格服務、促銷服務、庫存狀態/配送至服務、廣告詞服務、預售/秒殺服務、評價服務、試用服務、推薦服務、商品介紹服務、各品類相關的一些特殊服務。
常規解決方案:
前端通過ajax動態加載,服務端則把這些文案以html的形式緩存到Redis中,如下圖:
解剖:
一個詳情頁html 主體達平均150 kb, 那麼在500QPS 已接近千M局域網寬帶極限,所以必須減少內網通信。
2. Nginx緩存
針對上面佔滿內網帶寬的情況,可以在Ngxin這一層做靜態文件緩存,然後後臺維護商品的時候刪除緩存(修改商品→刪除緩存),架構圖如下:
3. 配置說明
代碼配置:
worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; upstream myApiTest { server localhost:9001; server localhost:9002; server localhost:9003; } #緩存模塊配置 proxy_cache_path /data/nginx/cache_ypf levels=1:2 keys_zone=cache_ypf:500m inactive=20d max_size=1g; server { listen 8080; server_name xxx; #隨意配置一個即可,優先走代理地址 location / { proxy_pass http://myApiTest; #緩存配置 # 指定緩存區(和上面的keys_zone對應) proxy_cache cache_ypf; #以全路徑md5值做做爲Key proxy_cache_key $host$uri$is_args$args; #對不同的HTTP狀態碼設置不同的緩存時間 proxy_cache_valid 200 304 12h; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } }
4. 如何清除緩存
需要藉助第三方模塊ngx_cache_purge來清除。
(1). 安裝模塊
#下載ngx_cache_purge 模塊包 ,這裏nginx 版本爲1.6.2 purge 對應2.0版 wget http://labs.frickle.com/files/ngx_cache_purge-2.3.tar.gz #查看已安裝模塊 ./sbin/nginx -V #進入nginx安裝包目錄 重新安裝 --add-module爲模塊解壓的全路徑 ./configure --prefix=/root/svr/nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/root/svr/packages/ngx_cache_purge-2.3 #重新編譯 make #拷貝 安裝目錄/objs/nginx 文件用於替換原nginx 文件 #檢測查看安裝是否成功 nginx -t
(2). 進行配置
location ~ /clear(/.*) { #允許訪問的IP allow 127.0.0.1; allow 192.168.0.193; #禁止訪問的IP deny all; #配置清除指定緩存區和路徑(與proxy_cache_key一至) proxy_cache_purge cache_luban $host$1$is_args$args; }
(3). 配置好後進行訪問。
# 訪問生成緩存文件 http://www.ypf.com/?a=1 # 清除生成的緩存,如果指定緩存不存在 則會報404 錯誤。 http://www.ypf.com/clear/?a=1
5. 實戰演示
windows下演示如下:
https://blog.csdn.net/weixin_34289744/article/details/91639502
Linux下演示:
後續補充
三. 性能調優
2. 每個worker 進程的最大連接數
語法:worker_connections number; 默認:worker_connections 1024
3. worker_cpu_affinity cpumask[cpumask……] 綁定Nginx worker進程到指定的CPU內核
爲什麼要綁定worker進程到指定的CPU內核呢?假定每一個worker進程都是非常繁忙的,如果多個worker進程都在搶同一個CPU,那麼這就會出現同步問題。反之,如果每一個worker進程都獨享一個CPU,就在內核的調度策略上實現了完全的併發。 例如,如果有4顆CPU內核,就可以進行如下配置: worker_processes 4; worker_cpu_affinity 1000 0100 0010 0001; 注意 worker_cpu_affinity配置僅對Linux操作系統有效。
4. Nginx worker 進程優先級設置
語法:worker_priority nice; 默認:worker_priority 0; 優先級由靜態優先級和內核根據進程執行情況所做的動態調整(目前只有±5的調整)共同決定。nice值是進程的靜態優先級,它的取值範圍是–20~+19,–20是最高優先級,+19是最低優先級。因此,如果用戶希望Nginx佔有更多的系統資源,那麼可以把nice值配置得更小一些,但不建議比內核進程的nice值(通常爲–5)還要小
5. Nginx worker進程可以打開的最大句柄描述符個數
語法: worker_rlimit_nofile limit; 默認:空 更改worker進程的最大打開文件數限制。如果沒設置的話,這個值爲操作系統的限制。設置後你的操作系統和Nginx可以處理比“ulimit -a”更多的文件,所以把這個值設高,這樣nginx就不會有“too many open files”問題了。
6. 是否打開accept鎖
語法:accept_mutex[on|off] 默認:accept_mutext on; accept_mutex是Nginx的負載均衡鎖,當某一個worker進程建立的連接數量達到worker_connections配置的最大連接數的7/8時,會大大地減小該worker進程試圖建立新TCP連接的機會,accept鎖默認是打開的,如果關閉它,那麼建立TCP連接的耗時會更短,但worker進程之間的負載會非常不均衡,因此不建議關閉它。
7. 使用accept鎖後到真正建立連接之間的延遲時間
語法:accept_mutex_delay Nms; 默認:accept_mutex_delay 500ms;