上一篇写到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大致能看出来。