要了解nginx的繼承模型，首先需要知道nginx使用多個配置塊進行操作。
在nginx中，這樣的塊被稱為上下文，例如，放置在伺服器上下文中的配置指令駐留在server 塊中，就像放置在http上下文中的指令駐留在http 塊中一樣。
nginx中有6種可能的上下文，這裡是從上到下的順序：
預設繼承模型是指令僅向下繼承。
從來沒有側身，絕對永遠不會。
這包括您在內部從乙個位置重寫請求到另乙個位置的情況 - 第乙個位置中的每個指令都被遺忘，只有第二個位置指令適用於位置上下文。
在繼承行為方面，nginx中有四種型別的配置指令：
normal指令是迄今為止最常見的指令，它遵循預設的繼承模型而沒有任何意外。
讓我們看乙個示例配置，顯示行為的情況。
serverarray指令很像普通指令，因為它們遵循標準繼承模型，它始終向下繼承並替換在更高上下文中指定的任何指令。//}}
可能令人困惑的是假設你新增到陣列。array
指令的行為是，如果在同一上下文中定義多個指令，則將新增到值，但如果在不同的上下文中定義多個指令，則較低的上下文將替換較高的上下文。
這意味著如果您希望它在多個上下文中存在，您有時需要雙重定義乙個值。
這種情況的乙個例子。
serveraction指令是它開始變得有趣的地方。}
它們被限制在乙個上下文中並且永遠不會向下繼承，但是它們可以在多個上下文中指定，並且在某些情況下將針對每個上下文執行。
rewrite指令是乙個action指令，允許在伺服器和位置上下文中執行兩個上下文。
server當然，它並不那麼簡單。}
在位置內有三種可能的上下文，乙個巢狀位置，乙個if和limit_except。
指令的行為實際上完全取決於定義它的模組。
如果在該上下文中允許，則所有normal和array指令都將正確繼承。
對於行動指令，故事有點不同。
通常它們不會繼承到巢狀位置，但最終取決於模組的預期，並且它可以在指令的基礎上有所不同。
這裡沒有使用nginx文件，所以你必須嘗試一下，看看nginx是否會抱怨。
為了更好地衡量，讓我們舉乙個最常見的行為示例以及它如何影響重寫：
server }}try_files指令與上面提到的每個其他操作指令大致相同，不同之處在於，如果放置在伺服器上下文中，nginx實際上會建立乙個偽位置，該位置是可能的最不具體的位置。
這意味著如果請求與定義的位置匹配，則不會執行try_files指令。
這意味著如果您有location / defined，那麼您有乙個匹配每個可能請求的位置，因此try_files永遠不會實際執行。
因此，如果可能的話，始終將try_files放在位置上下文而不是伺服器上下文中
nginx 工作模型
問題 對nginx 而言，乙個工作程序，只建立乙個工作執行緒，但可以開啟多個檔案。用ps ef l 可以檢視，l 可顯示lwp light weight process 和 nlwp number os light weigh process 列 難道對方用查詢方式看結果？還是採用通知？下面是查詢的...
Nginx程序模型
這篇主要是閱讀這篇博文的筆記。nginx採用的也是大部分http伺服器的做法，master，worker模型，基本的事件處理都是放在worker中，master負責一些全域性初始化，以及對worker的管理。nginx中的master和worker之間是通過socketpair來實現的，每次fork...
Nginx程序模型
目錄 1.nginx管理 工作程序模式 2.驚群 問題 為了支援現在流行的多cpu和多核架構，nginx使用了管理程序和工作程序的設計。架構設計如下圖所示 管理程序為工作程序的父程序，負責外部指令的接收，工作程序的狀態監管，負載均衡等 工作程序負責客戶端請求的處理和響應，工作程序一般是按照cpu的核...