上一篇寫到nginx的各個模組的配置資訊的儲存結構，大體描述了對配置資訊的配置項生成，定製，初始化過程。這裡重點研究實現定製的過程，所謂實現定製，這裡指的是，nginx系統提供使用者定義nginx的配置檔案(nginx.conf)，nginx系統來讀取這些檔案，根據使用者的定製提供相應的服務。這裡產生兩個問題
問題一是，nginx分析配置檔案的流程是怎麼樣的？
我們知道，nginx採取模組化管理，每一個模組針對nginx.conf配置檔案，都有關注的配置項，見下面的圖，例如， ngx_core_conf_t *ccf 關注 user， worker_processes等配置項
那麼將配置檔案的配置項對映到模組配置資訊的資料結構中，至少有兩種流程：
流程一：首先，一行一行讀取配置檔案，讀取一行，然後迴圈所有模組，檢視模組是否有指令關注該配置項，如果有，則將模組的對應配置資訊的資料做修改，如果沒有，則使用初始值。
流程二：首先，迴圈所有模組，針對每一個模組關注的配置項，從配置檔案中查詢是否有使用者定製，如果有，再做設定；沒有，則使用初始值。
通過系統原始碼，我們可以看到，使用的是流程一，至於使用流程一的原因，
首先， 配置檔案nginx.conf是供使用者定義，檔案大小並不確定，系統讀取配置檔案的流程，正常情況下，應該先將資料讀到記憶體裡面。否則，模組的每一個配置項設定都去開啟配置檔案，將極大增加系統的開銷；而如果讀到記憶體，則並不確定申請記憶體的大小，如果配置檔案過大，則會增加nginx的記憶體消耗。(當然，這裡說的讀到記憶體裡面，是可以對配置檔案做簡單分析，將資訊存到設計的一個數據結構裡面儲存。)
其次，面對可能的nginx的記憶體消耗，流程一則比較好解決。通過程式碼，我們可以看到，nginx設計了一個buffer，利用buffer去分次讀取nginx.conf中的配置資訊。
問題二是，nginx是怎樣定義配置檔案的格式的？
nginx配置檔案的格式，我們從nginx.conf大致能看出來。