目錄

Nginx快取機制介紹

Nginx快取機制的作用

nginx快取機制簡述

Nginx快取支持

快取使用

proxy_cache_path引數詳解

快取清除機制分析

被動快取清除

快取加載

主動清除快取

Nginx程式運行原理分析

Nginx作業模式

多行程處理模型

多行程處理模型優點

Nginx為何要采用多行程模式？

Worker行程遇到的問題

解決

Worker與CPU的系結

linux服務器引數調整

修改組態檔

調整內容

生效配置

Nginx常規調整

Nginx快取機制介紹

Nginx中如何使用快取，快取機制是怎么樣的，而且Nginx快取是不會像redis這些一樣有自己的記憶體管理機制，池化等，它會依據檔案系統進行快取

Nginx快取機制的作用

• 快取能夠提升性能，學會Nginx中如何使用快取很重要，
• Nginx作為靜態資源服務器，靜態資源變動頻率小，快取能夠加速訪問，
• Nginx離用戶最近，啟用快取能更好的提高性能，結合Redis可以組成類似二級快取，

nginx快取機制簡述

nginx是沒做優化的，

Nginx快取支持

在官網中api模塊 設定， 都有自己的默認值，可以根據需要設定，

快取使用

在組態檔中， 主要是在http指令塊中存在

包括代理快取配置，定義的配置

events {
	# 并發連接數
    worker_connections  1024;
}
http {
    # JAVA服務器集群
	upstream app_servers {
		server 127.0.0.1:8080;	
#		server 127.0.0.1:8081;
	}
	# 代理快取配置 - 定義配置
	proxy_cache_path "./cache_data/" levels=2:1:2 keys_zone=hot_information_cache:256m inactive=1d max_size=1000g;  
	proxy_cache_path "./cache_data/" levels=2:1:2 keys_zone=cache2:256m inactive=30s max_size=30g;  
	server {
		# 監聽80埠
		listen	80;
		location / {
            # 開啟快取
            proxy_cache hot_information_cache;
            # 快取JAVA應用回傳的指定狀態的資料，快取時間時1天       
            proxy_cache_valid 200 206 304 301 302 1d;
            # 請求的url就是快取的key（根據實際業務場景匹配）       
            proxy_cache_key $uri$is_args$args;      
            
            # 設定傳遞給上游服務的請求頭，Host為客戶端host，默認為$proxy_host
            proxy_set_header Host $http_host;
            # 如果快取中沒找到，再去請求后端服務器
            proxy_pass http://app_servers;
		}
		
		# 該指令在商業版本Nginx Plus支持，可以通過第三方模塊ngx_cache_purge來替代
		# 資源有變化的時候清除快取
		location ~ /purge(/.*) {
			#設定只允許指定的IP來清除快取
			allow all;
			# allow 127.0.0.1;
			# deny all ;
			proxy_cache_purge hot_information_cache $1;
		}
	}
}

levels表示目錄層級 3級，

后面對應的引數，包括proxy_cache_path 快取的路徑 和快取空間名、大小等配置，啟用快取proxy_cache 等，

proxy_cache_path 可以配置多個的，

keys_zone=cache2:256m 這里定義的是 空間名稱 和大小，

proxy_cache_valid 快取JAVA應用回傳的指定狀態的資料，快取時間時1天

proxy_cache_key 請求的url就是快取的key

proxy_set_header 設定傳遞給上游服務的請求頭，

通過這些指令 可以開啟快取，

快取清除機制分析

對于記憶體和磁盤滿了，nginx如何清除的，以及會不會像redis去池化會不會有碎片化的處理，

快取自己有快取管理行程

被動快取清除

proxy_cache_path 中可以通過以下指令來管理快取

• max_size 指定快取大小，快取管理行程監控快取是否超過指定值，超過該大小則通過LRU演算法來 淘汰資料，一次迭代洗掉的資料通過下面的引數來指定，
• manager_files 一次迭代程序中洗掉的項的數量，默認100個
• manager_threshold 一次迭代操作的持續時間限制，默認200毫秒
• manager_sleep 兩次迭代的間隔時間，默認50毫秒

快取加載

proxy_cache_path中可以通過以下引數來調整加載快取 Nginx啟動一分鐘后，快取加載行程被激活，存盤在檔案系統上先前快取的資料將被加載到 快取區中，整個加載是在迭代中完成的，一次加載

• loader_files 一次迭代加載不超過指定數目的項，默認100，
• loader_threshold 一次迭代操作的持續時間限制，默認200毫秒
• loader_sleep 兩次迭代的間隔時間，默認50毫秒

主動清除快取

proxy_cache_path中可以通過以下引數來調整主動清除快取

• purger：on開啟快取清除行程，遍歷所有快取條目并洗掉匹配到的鍵的快取資料
• purger_files 一次迭代程序中掃描的項的數量，默認10個
• purger_threshold 一次迭代的持續時間，默認50毫秒
• purger_sleep 兩次迭代的間隔時間，默認50毫秒

該指令在商業版本Nginx Plus支持，可以通過第三方模塊ngx_cache_purge來替代

location ~ /purge(/.*) {
			#設定只允許指定的IP來清除快取
			allow all;
			# allow 127.0.0.1;
			# deny all ;
			proxy_cache_purge hot_information_cache $1;
		}

ngx_cache_purge是一個第三方的nginx快取主動清除模塊，集成方便，使用簡單，下面我們就來學習如何安裝使用它，本節內容基于第一課安裝的Nginx基礎進行，這里我們只是再編譯增加模塊，

Nginx快取主動清除插件ngx_cache_purge 提取碼：d8eq

Nginx程式運行原理分析

nginx在運行時，架構是怎么樣的，架構 作業模式；從行程來看有 master 和worker行程，

Nginx作業模式

Nginx中的Master、Worker兩種行程，

Master行程

負責加載配置、接收命令、監控子行程，Master行程也是可以關閉的

Worker行程

負責處理網路請求，Worker行程的個數由組態檔決定，一般和CPU個數相關（有利于行程切換），配置幾個就有幾個Worker行程，需要說明的是，在nginx多行程中，每個worker都是平等的，因此每個行程處理外部請求的

機會權重都是一致的，

按理來說 worker行程處理請求的機會是一樣的，

這個流程模型和netty上的網路模型，都是很像的，網路請求，

多行程處理模型

多行程模型的處理方式

• 首先，master行程一開始就會根據我們的配置，來建立需 要listen的網路socket fd，然后fork出多個worker行程，

• 其次，根據行程的特性，新建立的worker行程，也會和 master行程一樣，具有相同的設定，因此，其也會去監聽 相同ip埠的套接字socket fd，
• 然后 ，多個worker行程監聽同樣設定的socket fd，當有 一個請求進來，所有的worker都會感知，
• 最后 ，監聽成功的worker行程，讀取請求，決議處理，響 應資料回傳給客戶端，斷開連接，結束，因此，一個request請求，只需要worker行程就可以完成，

  

多行程處理模型優點

Nginx為何要采用多行程模式？

• 行程之間是獨立的，當一個worker行程出現例外退出，其他worker行程不會受到影響；
• 獨立行程也會避免一些不需要的鎖操作，這樣能提高處理效率，開發除錯也更容易，

單純的 多行程模型會導致連接并發數量降低 ， 異步非阻塞IO模型 能解決這個問題，還能避

免 多執行緒背景關系切換導致 的性能損失，

多行程模型+異步非阻塞模型是一個非常好的選擇，

跟NIO、Netty執行緒模型思想一致，只不過一個是執行緒級、一個是行程級，

Worker行程遇到的問題

出現驚群效應

多個worker子行程監聽相同埠的設計，這樣多個子行程在accept建立新連接時會有爭搶，這會帶來 著名的“驚群”問題，子行程數量越多問題越明顯，這會造成系統性能下降，建立新連接時Nginx是如 何避免出現“驚群”現象的呢？

Worker行程負載不均衡

多個子行程爭搶處理一個新連接事件，最終只有一個worker子行程成功建立連接，隨后，它會一直處 理這個連接直到連接關閉，

如果有的子行程很“勤奮”，它們搶著建立并處理了大部分連接，而有的子行程則“運氣不好”，只 處理了少量連接，

解決

Nginx 的 Post佇列

將epoll 產生的事件分開，新連接事件的

• ngx_posted_accept_events佇列優先執行，普通事件的
• ngx_posted_events佇列最后執行

accept_mutex

Nginx采用了一個是否打開accept_mutex選項的值，控制worker行程是否需要去競爭鎖，打開accept_mutex鎖，能很好解決accept精確問題

ngx_accept_disabled

worker行程進行負債均衡閾的判斷值，處理的連接總數沒有達到7/8，不會搶accept鎖，達到時，則需要槍鎖，它解決了負載均衡的問題，

這是module中代碼，

Worker與CPU的系結

Worker行程跟CPU個數有關，但是如果多個Worker行程在同一個CPU上面爭奪資源也非常消耗性能，Nginx中有一個 worker_cpu_affinity 配置，能夠將worker系結到對應的CPU上面，

單個Worker行程處理的并發連接數配置

linux服務器引數調整

當TCP TIME_WAIT套接字數量經常達到兩、三萬，服務器很容易被拖死，需要減少Nginx服務器的TIME_WAIT套接字數量，

這個和netty對于服務器引數調整是一樣的，都是例如統同時保持TIME_WAIT套接字的最大數量，以及最大連接數等等，

修改組態檔

sudo vim /etc/sysctl.conf

調整內容

# 表示如果套接字由本端要求關閉，這個引數決定了它保持在FIN-WAIT-2狀態的時間，
# 由于某種原因服務端主動關閉連接，連接進入FIN_WAIT2狀態,該狀態是沒有超時的
# 如果客戶端不關閉，這個FIN_WAIT_2狀態將保持到系統重新啟動，越來越多的FIN_WAIT_2狀態會致使內核crash
net.ipv4.tcp_fin_timeout = 30
# 表示當keepalive起用的時候，TCP發送keepalive訊息的頻度，預設是2小時，改為20分鐘，
net.ipv4.tcp_keepalive_time = 1200
# 表示開啟SYN Cookies，當出現SYN等待佇列溢位時，啟用cookies來處理，
# 可防范少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_syncookies = 1
# 表示開啟重用，允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse = 1
# 表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認為0，表示關閉，
net.ipv4.tcp_tw_recycle = 1
# 表示用于向外連接的埠范圍，預設情況下很小：32768到61000，改為1024到65000，
net.ipv4.ip_local_port_range = 1024    65000
# 表示SYN佇列的長度，默認為1024，加大佇列長度為8192，可以容納更多等待連接的網路連接數，
net.ipv4.tcp_max_syn_backlog = 8192
# 表示系統同時保持TIME_WAIT套接字的最大數量，如果超過這個數字，TIME_WAIT套接字將立刻被清除并列印警告資訊，默認為180000，改為5000，對于Apache、Nginx等服務器，上幾行的引數可以很好地減少TIME_WAIT套接字數量，但是對于Squid，效果卻不大，此項引數可以控制TIME_WAIT套接字的最大數量，避免Squid服務器被大量的TIME_WAIT套接字拖死，
net.ipv4.tcp_max_tw_buckets = 5000

生效配置

sudo /sbin/sysctl -p

Nginx常規調整