5-nginx infrastructure design

I. Excellent modular design (1) highly abstract Module Interface all modules follow the same ngx_module_t interface design specifications. (2) The Module Interface is simple and flexible. The basic Module Interface ngx_module_t is simple enough. It only involves the initialization, exit, and configuration item processing of the module, which at the same time brings sufficient flexibility, yes, nginx has implemented dynamic modification in a relatively simple way, that is, to make the system function change while the service is running normally.

102 struct ngx_module_s {103 ngx_uint_t ctx_index; // index of the current module in a certain type of module 104 ngx_uint_t index; // the serial number of the current module in the ngx_modules array 105 ngx_uint_t spare0; 106 million; 108 ngx_uint_t spare2; 109 ngx_uint_t spare3; 110 111 ngx_uint_t version; 112 113 void * CTX; // point to the Context Structure of a class of modules. The public interface of a specific type of modules is 114 ngx_command_t * commands; // Process configuration item 115 ngx_uint_t type; // module type 116 117 ngx_int_t (* init_master) (ngx_log_t * log); // The framework never uses 118 11 9 ngx_int_t (* init_module) (ngx_cycle_t * cycle); // called when all modules are initialized. In master/worker mode, 120 121 ngx_int_t (* init_process) (ngx_cycle_t * cycle) is completed before the promoter process; // normal server calls 122 ngx_int_t (* init_thread) (ngx_cycle_t * cycle); 123 void (* exit_thread) (ngx_cycle_t * cycle); 124 void (* exit_process) (ngx_cycle_t * cycle ); // Call 125 126 void (* exit_master) (ngx_cycle_t * cycle) before the service is stopped; // call 127 128 uintptr_t spare_hook0; 129 bytes spare_hook1; 130 bytes spare_hook2; 131 uintptr_t spare_hook3; 132 uintptr_t spare_hook4; 133 uintptr_t spare_hook5; 134 uintptr_t spare_hook6; 135 uintptr_t spare_hook7; 136 };

In the preceding code, CTX, a member of the void * type, is generally used to indicate the universal interfaces of one type module in different types. (3) design the relationship between machines of common nginx modules in multi-level and multi-category modules: You can note that the ngx_module_t interface has a type member, indicates the concept that nginx Allows defining module types during module design. The configuration module has only one ngx_conf_module. The configuration module is the basis of all modules and implements the parsing function of the most basic configuration items (that is, parsing the nginx. conf file ). Nginx defines a basic type of module: Core module. The module type is ngx_core_module. The purpose of defining the core module is to make the non-modular framework code focus only on and how to call six core modules. The common features of the event module, HTTP module, and mail module are: in fact, each of them has one module in the core module as its own spokesperson, one module is used as the core business and management function in similar modules. The event module is the basis of the HTTP and mail modules. II. The event-driven architecture nginx adopts a complete event-driven architecture to handle services, which is different from traditional Web servers (such as APACHE. For traditional Web servers, the so-called event-driven mechanism is usually limited to the establishment and closure of TCP connections. After a connection is established, all operations before it is closed are no longer event-driven, and the batch processing mode for each operation in order will be degraded, in this way, after a connection is established, each request will always occupy system resources until the connection is closed. This traditional Web server uses a process or thread as the event consumer. When an event generated by a request is processed by this process, process resources will be occupied by this request until the processing of this request ends. Nginx does not use processes or threads as event consumers. The so-called event consumers can only be a module (there is no process concept here ). Only Event collectors and distributors are eligible to use process resources. They call the event consumption module when distributing an event to use the resources currently occupied. A simple model of nginx event processing, for example, shows the important difference between a traditional Web server and nginx from the preceding content: the former is that each event consumer excludes a process resource, the event consumer of the latter is called by the event distributor for a short time. This design improves network performance and user-perceived request latency, and responds to events generated by each user's request in a timely manner, the network throughput of the entire server increases with the timely response of events. However, this also brings about a problem: the consumer of the event cannot block the behavior. Otherwise, other events will not be responded to in a timely manner due to the long time occupation of the event distributor process. 3. Multi-phase asynchronous request processing is implemented based on the event-driven architecture. The process of processing a request is divided into multiple nodes according to the event trigger method. Each stage is triggered by the event collection and distributor. Its Advantage: This design works with the event-driven architecture to greatly improve the network performance and make every process fully run without or as few process sleep conditions as possible. Once a process is sleep, it will inevitably reduce the number of concurrent event processing, which will certainly reduce network performance and increase the average latency of request processing time. In this case, if the network performance cannot meet the business needs, the number of processes can only be increased. If the number of processes is too large, additional operations on the operating system kernel will be added: inter-process switching. Frequent process switching still consumes CPU and other resources, thus reducing network performance. At the same time, sleep processes will not effectively release the memory occupied by the process, which will inevitably lead to a decrease in the available memory of the system, thus affecting the maximum number of concurrent connections that the system can process. References: Understanding nginx