As a well-known high-performance server in the industry, Nginx is widely used. Its high performance is due to its excellent architecture design. Its architecture mainly includes these points: modular design, event-driven architecture, multi-stage asynchronous processing of requests, management process and multi-work process design, memory pool design, as follows The content will be explained in turn.
From redis, memcached to Nginx to
realize Nginx module development
Nginx to realize business Nginx connect mysq| A streaming media server through Nginx
Modular design
The highly modular design is the foundation of Nginx's architecture. In Nginx, except for a small amount of core code, everything else is a module.
All modules are divided into levels and categories. Nginx officially has five types of modules: core module, configuration module, event module, HTTP module, and mail module. The relationship between them is as follows: 
Among these five modules, the configuration module and the core module are closely related to the Nginx framework. The event module is the basis of the HTTP module and the mail module. The "status" of the HTTP module and the mail module are similar, they both focus more on the application level.
Event-driven architecture
The event-driven architecture, in simple terms, is that events are generated by some event source, the event collector collects and distributes the events, and then the event processor handles these events (the event processor needs to register itself in the event collector Event processed).
For the Nginx server, events are generally generated by network cards and disks. The event module in Nginx will be responsible for the collection and distribution of events; all modules may be event consumers, and they first need to register interesting events with the event module Type, so that when an event occurs, the event module will distribute the event to the corresponding module for processing.
For traditional web servers (such as Apache), the so-called event-driven use is often limited to TCP connection establishment and closing events. After a connection is established, all operations before it is closed are no longer event-driven, and will degenerate at this time It is a batch mode that executes each operation in sequence, so that each request will always occupy system resources after the connection is established, and the resources will not be released until it is closed. This mode of request occupies server resources waiting to be processed will cause a great waste of server resources. As shown in the figure below, traditional web servers often regard a process or thread as a time consumer. When an event generated by a request is processed by the process, the process resources will be occupied by the request until the request is processed. A typical example is the multi-process mode of Apache synchronous blocking.
The simple model of traditional web server processing events (rectangle represents the process):
Nginx uses an event-driven architecture to process business, which is different from traditional web servers. It does not use processes or threads as event consumers. The so-called event consumer can only be a module. Only event collectors and distributors are eligible to occupy process resources. They will call the event consumption module to use the currently occupied process resources when distributing an event, as shown in the following figure, which lists 5 different events. In the one-time processing of event collection and distributor process, after these 5 events are collected in order, the current process will be used to distribute events, and the corresponding event consumers will be called to process the events. Of course, this kind of distribution and invocation is also orderly.
A simple model of Nginx handling events:
As can be seen from the above figure, when processing request events, Nginx's event consumers are only called by the event distributor process for a short time. This design improves network performance and user-perceived request latency. Each user's request The generated event will respond in time, and the network throughput of the entire server will increase due to the timely response to the event. Of course, this also brings certain requirements, that is, each event consumer must not have blocking behavior, otherwise it will take a long time to occupy the event distributor process and cause other events to fail to respond in time. The non-blocking feature of Nginx is due to Its modules meet this requirement.
Multi-stage asynchronous processing of requests
Multi-stage asynchronous processing of requests is closely related to event-driven architecture, that is, multi-stage asynchronous processing of requests can only be implemented based on event-driven architecture. Multi-stage asynchronous processing is to divide the processing of a request into multiple stages according to the triggering method of the event, and each stage can be triggered by the event collector and dispatcher.
When processing HTTP requests for static files, the segmentation phases and the triggering events of each phase are as follows: 
If you want to learn Java engineering, high performance and distributed, explain the profound things in a simple way. Friends of microservices, Spring, MyBatis, Netty source code analysis can add my Java advanced communication: 854630135, there are Ali Daniels live explanation technology in the group, and videos of Java large-scale Internet technology to share with you for free.
In this example, the request is roughly divided into 7 stages. These stages can happen repeatedly. Therefore, a request for downloading static resources may be broken down into hundreds or thousands due to factors such as too large request data and unstable network speed. The stages listed in the figure above.
Asynchronous processing and multi-stage complement each other. Only when the request is divided into multiple stages can there be so-called asynchronous processing. When a time is distributed to the event consumer for processing, the event consumer processing the event is only equivalent to the stage of processing 1 request. When can the next stage be processed? This can only wait for the kernel's notification, that is, when the next event occurs, event dispatchers such as epoll will get the notification, and then call the event consumer for processing.
Management process, multi-work process design
After Nginx is started, there will be a master process and multiple worker processes. The master process is mainly used to manage the worker process, including receiving signals from the outside world, sending signals to each worker process, monitoring the running status of the worker process, and starting the worker process. The worker process is used to process the request event from the client. Multiple worker processes are peer-to-peer. They compete equally for requests from clients. Each process is independent of each other. A request can only be processed in one worker process. The number of worker processes can be set. Generally, the setting is consistent with the number of CPU cores of the machine. The reason for this is related to the event processing model. The Nginx process model can be represented by the following figure: 
View the Nginx process on the server: 
This design brings the following advantages:
1) Utilize the concurrent processing capabilities of multi-core systems
Modern operating systems already support multi-core CPU architecture, which allows multiple processes to occupy different CPU cores to work. All worker processes in Nginx are completely equal. This improves network performance and reduces the latency of requests.
2) Load balancing
Multiple worker worker processes achieve load balancing through inter-process communication, that is, when a request comes, it is easier to be assigned to the worker process with a lighter load for processing. This also improves network performance to a certain extent and reduces the latency of requests.
3) The management process will be responsible for monitoring the status of the work process and managing its behavior
The management process does not occupy much system resources, it is only used to start, stop, monitor or use other behaviors to control the work process. First of all, this improves the reliability of the system. When there is a problem with the worker process, the management process can start a new worker process to avoid system performance degradation. Secondly, the management process supports operations such as program upgrades and configuration item modification during the running of the Nginx service. This design makes dynamic scalability and dynamic customization easier to achieve.
The design of the memory pool
In order to avoid memory fragmentation, reduce the number of requests for memory from the operating system, and reduce the development complexity of each module, Nginx has designed a simple memory pool. Its main function is to integrate multiple applications for memory from the system into one operation. It greatly reduces the consumption of CPU resources and at the same time reduces memory fragmentation.
Therefore, each request usually has a simple independent memory pool (for example, each TCP connection is allocated a memory pool), and the entire memory pool will be destroyed at the end of the request, and the once allocated memory will be returned to the operation at one time system. This design greatly improves the simplicity of module development, because the module does not care about its release after applying for memory; and because the number of allocated memory is reduced, the request execution delay is reduced. At the same time, by reducing memory fragmentation, the effective utilization of memory and the number of concurrent connections that the system can handle are improved, thereby enhancing network performance.
Technical Exchange Group: [960994558] Sorted out some good study books, interview questions from big companies, and popular technology teaching video materials to share in it (including C/C++, Linux, Nginx, ZeroMQ, MySQL, Redis, fastdfs, MongoDB, ZK, streaming media, CDN, P2P, K8S, Docker, TCP/IP, coroutine, DPDK, etc.), you can add it yourself if you need it! ~
