Nginx 架构设计：Master-Worker 模式与事件驱动

原创 已于 2026-04-06 09:48:40 修改 · 468 阅读 · 5 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
收录于
后端技术源码解读

当前文章被收录于：

后端技术源码解读
50 篇文章 0 人学习

解读Java后端常用技术栈

订阅专栏 查看详情
于 2026-04-05 10:00:02 首次发布

Nginx 架构设计：Master-Worker 模式与事件驱动

深入剖析 Nginx 高性能的秘密
本文基于 Nginx 1.24.0 源码，从 Master-Worker 进程模型、事件驱动机制、惊群效应处理等维度，全面解析 Nginx 如何通过精妙的架构设计实现百万级并发处理能力。

目录

  1. 引言：Nginx 高性能的密码
  2. Master-Worker 多进程模型
  3. 事件驱动机制：Reactor 模式的完美实践
  4. 惊群效应与解决方案
  5. 核心源码剖析
  6. 性能调优实战
  7. 总结与展望

1. 引言：Nginx 高性能的密码

在当今互联网架构中，Nginx 已经成为高性能 Web 服务器和反向代理的代名词。从个人博客到全球Top 1000的网站，Nginx 凭借其卓越的并发处理能力和稳定性，赢得了无数开发者的青睐。

但你是否思考过：为什么单机 Nginx 能够轻松处理百万级并发连接？ 答案隐藏在其精心设计的架构中——Master-Worker 多进程模型与事件驱动机制的完美结合。

本文将深入 Nginx 源码（基于 1.24.0 版本），通过流程图、对比表格和代码示例，全面剖析 Nginx 的架构设计精髓。

2. Master-Worker 多进程模型

2.1 架构概览

Nginx 采用经典的 Master-Worker 多进程架构，这种设计巧妙地结合了多进程的稳定性和单线程的高效性。

监控

管理

信号

Master Process
主进程

Worker Process 1

Worker Process 2

Worker Process N

epoll_wait

epoll_wait

epoll_wait

处理客户端请求

处理客户端请求

处理客户端请求

核心职责划分：

进程类型主要职责特点
Master 进程• 读取配置文件
• 创建/监控 Worker 进程
• 处理信号（reload、quit）
• 管理进程生命周期		不处理业务请求，仅管理
Worker 进程• 监听端口（accept）
• 处理客户端请求
• 执行业务逻辑
• 与后端服务器通信		独立运行，互不干扰

2.2 Master 进程工作流程

Master 进程是整个 Nginx 的"大脑"，它负责统筹管理所有 Worker 进程。

子进程退出

配置重载

快速停止

优雅停止

Nginx 启动

初始化核心模块

读取配置文件 nginx.conf

创建监听 socket bind/listen

创建 Worker 进程池

进入监控循环

收到 SIGCHLD?

收到 SIGHUP?

收到 SIGTERM?

收到 SIGQUIT?

回收 Worker 进程

重启 Worker

重新加载配置

平滑启动新 Worker

优雅关闭旧 Worker

立即终止所有进程

等待处理完请求

程序退出

核心源码分析（Nginx 1.24.0）：

// src/os/unix/ngx_process_cycle.c

void
ngx_master_process_cycle(ngx_cycle_t *cycle)
{
    char              *title;
    u_char            *p;
    size_t             size;
    ngx_int_t          i;
    ngx_uint_t         n, sigio;
    sigset_t           set;
    struct itimerval   itv;
    ngx_uint_t         live;
    ngx_msec_t         delay;
    ngx_core_conf_t   *ccf;

    // 设置进程标题
    size = sizeof(master_process);
    
    // 设置信号屏蔽
    sigemptyset(&set);
    sigaddset(&set, SIGCHLD);
    sigaddset(&set, SIGALRM);
    sigaddset(&set, SIGIO);
    sigaddset(&set, SIGINT);
    sigaddset(&set, ngx_signal_value(NGX_RECONFIGURE_SIGNAL));
    sigaddset(&set, ngx_signal_value(NGX_REOPEN_SIGNAL));
    sigaddset(&set, ngx_signal_value(NGX_NOACCEPT_SIGNAL));
    sigaddset(&set, ngx_signal_value(NGX_TERMINATE_SIGNAL));
    sigaddset(&set, ngx_signal_value(NGX_SHUTDOWN_SIGNAL));
    sigaddset(&set, ngx_signal_value(NGX_CHANGEBIN_SIGNAL));

    if (sigprocmask(SIG_BLOCK, &set, NULL) == -1) {
        ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
                      "sigprocmask() failed");
    }

    // 启动 Worker 进程
    ngx_start_worker_processes(cycle, ccf->worker_processes,
                               NGX_PROCESS_RESPAWN);

    // 进入 Master 主循环
    for ( ;; ) {
        // 等待信号
        sigsuspend(&set);

        // 处理各种信号
        if (ngx_reap) {
            ngx_reap = 0;
            ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "reap children");

            live = ngx_reap_children(cycle);  // 回退出的子进程
        }

        if (!live && (ngx_terminate || ngx_quit)) {
            // 所有 Worker 都已退出，Master 也可以退出
            ngx_master_process_exit(cycle);
        }

        // 处理 SIGHUP：重载配置
        if (ngx_reconfigure) {
            ngx_reconfigure = 0;
            
            // 重新加载配置
            ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reconfiguring");

            cycle = ngx_init_cycle(cycle);
            if (cycle == NULL) {
                cycle = (ngx_cycle_t *) ngx_cycle;
                continue;
            }

            ngx_cycle = cycle;
            ngx_start_worker_processes(cycle, ccf->worker_processes,
                                       NGX_PROCESS_RESPAWN);
        }

        // 处理 SIGQUIT：优雅退出
        if (ngx_quit) {
            ngx_quit = 0;
            ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0,
                          "gracefully shutting down");
            ngx_set_shutdown_timer(cycle);
            ngx_worker_processes = ccf->worker_processes;
            ngx_noaccepting = 1;
            ngx_signal_worker_processes(cycle,
                                        ngx_signal_value(NGX_SHUTDOWN_SIGNAL));
        }
        
        // ... 其他信号处理
    }
}

2.3 Worker 进程工作流程

每个 Worker 进程都是独立的，它们共享监听 socket，但通过 accept_mutex 锁 来避免惊群效应。

客户端 listen socket epoll Worker 进程 客户端 listen socket epoll Worker 进程 1. 调用 epoll_wait() 2. 等待事件... 3. 被唤醒 4. 尝试获取 accept_mutex alt [获取锁成功] [获取锁失败] epoll_wait(events) SYN (新连接) 产生可读事件 返回 listen_fd 可读 ngx_accept_mutex_lock() accept() conn_fd epoll_ctl(ADD, conn_fd) 处理请求 ngx_accept_mutex_unlock() 放弃本次 accept epoll_wait() 继续等待

Worker 核心循环源码：

// src/os/unix/ngx_process_cycle.c

static void
ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data)
{
    ngx_int_t worker = (intptr_t) data;

    ngx_process = NGX_PROCESS_WORKER;
    ngx_worker = worker;

    // 初始化 Worker
    ngx_worker_process_init(cycle, worker);

    ngx_setproctitle("worker process");

    // 进入 Worker 事件循环
    for ( ;; ) {
        // 处理事件
        ngx_process_events_and_timers(cycle);

        // 检查退出信号
        if (ngx_terminate || ngx_quit) {
            ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0,
                          "exiting");
            ngx_worker_process_exit(cycle);
        }

        // 检查重开日志信号
        if (ngx_reopen) {
            ngx_reopen = 0;
            ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0,
                          "reopening logs");
            ngx_reopen_files(cycle, (ngx_uint_t) -1);
        }
    }
}

2.4 多进程 vs 多线程对比

为什么 Nginx 选择多进程而非多线程？这是一个经典的架构设计问题。

对比维度Nginx 多进程模型Apache 多线程模型优势方
稳定性进程隔离，一个崩溃不影响其他线程共享内存，崩溃可能影响整体✅ Nginx
CPU 利用多核并行，充分利用 CPU线程切换开销大✅ Nginx
开发复杂度进程间通信需要 IPC共享内存，通信简单✅ Apache
内存占用每个进程独立内存空间线程共享内存，占用少✅ Apache
上下文切换进程切换开销大线程切换开销小✅ Apache
锁竞争几乎无锁需要锁保护共享数据✅ Nginx
单机并发10万+ 无压力受限于线程数量✅ Nginx

Nginx 设计哲学：

“用空间换稳定，用进程隔离换取系统级容错。每个 Worker 崩溃只会影响当前连接，不会导致整个服务宕机。”

3. 事件驱动机制：Reactor 模式的完美实践

3.1 Reactor 模式解析

Nginx 的事件驱动基于经典的 Reactor 模式，这是一种将事件多路复用和事件分发结合的设计模式。

注册

回调

客户端请求

操作系统内核

epoll/kqueue

事件分发器

事件处理器

业务逻辑

Reactor 核心组件：

  1. Handle（句柄）：标识 I/O 资源（socket、文件等）
  2. Event Demultiplexer（事件分离器）：epoll、kqueue、/dev/poll
  3. Event Handler（事件处理器）：处理 I/O 事件的回调函数
  4. Reactor（反应器）：核心事件循环
  5. Concrete Event Handler：具体业务处理逻辑

3.2 Nginx 事件驱动流程

返回事件

是

否

是

否

是

否

事件循环开始

初始化事件模块

设置定时器

调用 epoll_wait

处理事件

有定时器到期?

有就绪事件?

执行定时器回调

有 postponed 事件?

遍历就绪事件队列

事件后处理

处理 postponed

核心源码：

// src/event/ngx_event.c

void
ngx_process_events_and_timers(ngx_cycle_t *cycle)
{
    ngx_uint_t  flags;
    ngx_msec_t  timer, delta;

    // 如果使用 accept_mutex，需要获取锁
    if (ngx_use_accept_mutex) {
        // 计算下次定时器到期时间
        if (ngx_accept_mutex_delay > 0) {
            timer = ngx_accept_mutex_delay;
        } else {
            timer = ngx_event_find_timer();
        }

        // 尝试获取 accept_mutex 锁
        if (ngx_accept_mutex_lock(timer) != NGX_OK) {
            return;  // 获取失败，跳过本次事件处理
        }

        // 获取锁成功，监听 listen socket
        if (ngx_accept_mutex_held) {
            flags |= NGX_POST_EVENTS;
        }
    } else {
        timer = ngx_event_find_timer();
    }

    // 计算时间差（用于更新时间缓存）
    delta = ngx_current_msec;

    // 调用事件处理模块（epoll、kqueue 等）
    (void) ngx_process_events(cycle, timer, flags);

    delta = ngx_current_msec - delta;

    ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
                   "timer delta: %M", delta);

    // 处理到期定时器
    ngx_event_process_posted(cycle, &ngx_posted_accept_events);
    
    if (ngx_accept_mutex_held) {
        ngx_accept_mutex_unlock();
    }

    // 处理普通事件
    if (delta) {
        ngx_event_expire_timers();
    }

    ngx_event_process_posted(cycle, &ngx_posted_events);
}

3.3 epoll vs select vs poll

Nginx 在 Linux 上默认使用 epoll，这是高性能的关键。

特性selectpollepoll (Linux)kqueue (BSD)
最大连接数1024 (FD_SETSIZE)无限制无限制无限制
性能O(n) 线性扫描O(n) 线性扫描O(1) 事件驱动O(1) 事件驱动
内存拷贝每次调用都要拷贝 fd_set每次调用都要拷贝 pollfd通过 mmap 共享内存通过 mmap 共享内存
支持平台所有 POSIX 系统所有 POSIX 系统Linux 2.6+FreeBSD/macOS
触发方式LT（水平触发）LTLT + ET（边缘触发）LT + ET

epoll 核心优势：

// epoll 使用示例（简化版）

// 1. 创建 epoll 实例
int epfd = epoll_create1(0);

// 2. 添加监听的 socket
struct epoll_event ev;
ev.events = EPOLLIN;  // 监听可读事件
ev.data.fd = listen_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

// 3. 事件循环
struct epoll_event events[MAX_EVENTS];
while (1) {
    // 等待事件（O(1) 复杂度）
    int nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);
    
    // 处理就绪事件
    for (int i = 0; i < nfds; i++) {
        if (events[i].data.fd == listen_fd) {
            // 新连接
            int conn_fd = accept(listen_fd, NULL, NULL);
            
            // 添加到 epoll
            ev.data.fd = conn_fd;
            ev.events = EPOLLIN | EPOLLET;  // 使用边缘触发
            epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);
        } else {
            // 处理客户端数据
            int fd = events[i].data.fd;
            // ... 读写操作
        }
    }
}

3.4 Nginx 事件模块架构

Nginx 将事件处理抽象为模块，不同平台使用不同的 I/O 多路复用机制。

ngx_events_module
核心事件模块

ngx_epoll_module
Linux epoll

ngx_kqueue_module
FreeBSD/macOS

ngx_select_module
通用 select

ngx_poll_module
通用 poll

ngx_devpoll_module
Solaris /dev/poll

epoll_create
epoll_ctl
epoll_wait

kqueue
kevent

select
FD_SET/FD_CLR

poll

ioctl /dev/poll

模块加载顺序：

# nginx.conf
events {
    use epoll;  # 明确指定使用 epoll
    worker_connections 10240;
}

# 如果不指定 use，Nginx 会自动选择最优的事件模块
# 优先级：epoll > kqueue > /dev/poll > poll > select

4. 惊群效应与解决方案

4.1 什么是惊群效应

惊群效应（Thundering Herd）：当多个进程/线程同时监听同一个 socket 时，有连接到来，所有进程都被唤醒，但只有一个进程能成功 accept，其他进程都"白忙活"。

Worker N Worker 2 Worker 1 listen socket 客户端 Worker N Worker 2 Worker 1 listen socket 客户端 所有 Worker 都在 epoll_wait() 内核唤醒所有监听进程 白白被唤醒，浪费 CPU SYN (新连接) 📢 被唤醒 📢 被唤醒 📢 被唤醒 accept() accept() ❌ EAGAIN accept() ❌ EAGAIN SYN-ACK

惊群效应的危害：

影响说明
CPU 浪费大量进程被无意义唤醒，上下文切换频繁
吞吐下降单核性能下降，整体 QPS 降低
延迟增加真正处理请求的进程被其他唤醒操作阻塞

4.2 Nginx 的解决方案

Nginx 通过 accept_mutex 锁 来解决惊群问题。

否

是

获取成功

获取失败

epoll_wait 返回

listen 可读?

处理普通事件

尝试获取
accept_mutex

accept 新连接

跳过本次 accept

处理新连接

释放锁

继续等待下次事件

源码分析（Nginx 1.24.0）：

// src/event/ngx_event_accept.c

void
ngx_event_accept(ngx_event_t *ev)
{
    socklen_t             socklen;
    ngx_connection_t     *c;
    ngx_listening_t      *ls;
    ngx_socket_t          s;
    struct sockaddr     *sa;
    
    // 获取 accept_mutex 锁
    if (ngx_accept_mutex_lock) {
        if (!ngx_accept_mutex_held) {
            return;  // 未获取锁，直接返回
        }
    }

    ls = ev->data;

    // 循环 accept（处理 backlog）
    do {
        socklen = sizeof(struct sockaddr);
        
        // 接受新连接
        s = accept(ls->fd, sa, &socklen);
        
        if (s == (ngx_socket_t) -1) {
            err = ngx_socket_errno;

            if (err == NGX_EAGAIN) {
                // 没有新连接了
                break;
            }

            // 其他错误处理
            ngx_log_error(NGX_LOG_ALERT, ev->log, err,
                          "accept() failed");
            return;
        }

        // 创建连接对象
        c = ngx_get_connection(s, ev->log);
        if (c == NULL) {
            if (ngx_close_socket(s) == -1) {
                ngx_log_error(NGX_LOG_ALERT, ev->log, ngx_socket_errno,
                              "close() failed");
            }
            return;
        }

        // 设置连接属性
        c->type = SOCK_STREAM;
        c->listening = ls;
        
        // 将新连接添加到 epoll
        if (ngx_add_conn) {
            if (ngx_add_conn(c) == NGX_ERROR) {
                ngx_close_connection(c);
                return;
            }
        }

    } while (ev->available > 0);  // 处理多个连接

    // 释放 accept_mutex 锁
    if (ngx_accept_mutex_lock) {
        ngx_accept_mutex_unlock();
    }
}

4.3 accept_mutex 锁的实现

Nginx 使用文件锁（flock）来实现 accept_mutex。

锁类型Nginx 实现说明
锁机制文件锁（flock）跨进程同步
锁位置/path/to/nginx_accept_mutex.lock可配置路径
获取超时accept_mutex_delay（默认 500ms）防止饥饿
锁竞争非阻塞尝试 + 定时重试减少等待

配置参数：

events {
    accept_mutex on;              # 默认 on，开启 accept_mutex
    accept_mutex_delay 500ms;     # 获取锁失败后的等待时间
    worker_processes 4;           # Worker 数量
}

4.4 内核级解决方案：EPOLLEXCLUSIVE

Linux 4.5+ 引入了 EPOLLEXCLUSIVE 标志，可以在内核层面避免惊群。

Nginx 1.11.3+ 已支持：

// src/event/modules/ngx_epoll_module.c

static ngx_int_t
ngx_epoll_add_connection(ngx_connection_t *c)
{
    struct epoll_event  ee;

    ee.events = EPOLLIN|EPOLLOUT|EPOLLET|EPOLLRDHUP;
    
#if (NGX_HAVE_EPOLLEXCLUSIVE)
    ee.events |= EPOLLEXCLUSIVE;  // 内核级排他，避免惊群
#endif

    ee.data.ptr = (void *) ((uintptr_t) c | c->read->instance);

    ngx_log_debug2(NGX_LOG_DEBUG_EVENT, c->log, 0,
                   "epoll add connection: fd:%d ev:%04XD", c->fd, ee.events);

    if (epoll_ctl(ep, EPOLL_CTL_ADD, c->fd, &ee) == -1) {
        ngx_log_error(NGX_LOG_ALERT, c->log, ngx_errno,
                      "epoll_ctl(EPOLL_CTL_ADD, %d) failed", c->fd);
        return NGX_ERROR;
    }

    c->read->active = 1;
    c->write->active = 1;

    return NGX_OK;
}

版本对比：

Nginx 版本惊群解决方案
< 1.11.3仅 accept_mutex 锁
>= 1.11.3accept_mutex + EPOLLEXCLUSIVE（双保险）
>= 1.23.0默认开启 EPOLLEXCLUSIVE

5. 核心源码剖析

5.1 进程启动流程

单进程

Master-Worker

循环

循环

main 函数

ngx_init_cycle

运行模式

ngx_single_process_cycle

ngx_master_process_cycle

ngx_start_worker_processes

Fork 子进程

ngx_worker_process_cycle

ngx_worker_process_init

ngx_process_events_and_timers

ngx_init_cycle

ngx_process_events_and_timers

5.2 事件处理核心数据结构

// src/event/ngx_event.h

/* 事件结构体 */
struct ngx_event_s {
    void            *data;          // 事件关联的数据
    ngx_event_t     *next;          // 链表下一个节点
    ngx_uint_t       index;         // 在事件队列中的索引
    
    ngx_socket_t     fd;            // 文件描述符
    
    ngx_event_t     *prev;          // 用于posted事件队列
    ngx_event_t     *next;          // 用于posted事件队列
    
    /* 读写回调函数 */
    ngx_event_handler_pt  read_handler;    // 读事件处理
    ngx_event_handler_pt  write_handler;   // 写事件处理
    
    ngx_uint_t       instance;      // 实例计数器（防止 stale event）
    
    /* 使用的标志 */
    unsigned         instance:1;    // 实例标志
    unsigned         active:1;      // 是否在epoll中
    unsigned         disabled:1;    // 是否禁用
    unsigned         ready:1;       // 是否就绪
    unsigned         oneshot:1;     // 是否使用 EPOLLONESHOT
    unsigned         complete:1;    // 是否完成
    unsigned         eof:1;         // 是否到达文件末尾
    unsigned         error:1;       // 是否有错误
    
    unsigned         timedout:1;    // 是否超时
    unsigned         timer_set:1;   // 定时器是否已设置
    unsigned         delayed:1;     // 是否延迟处理
    unsigned         deferred_accept:1;  // 是否延迟accept
    unsigned         accept:1;      // 是否是accept事件
    
    /* 事件类型 */
    unsigned         read:1;        // 读事件
    unsigned         write:1;       // 写事件
    
    unsigned         timer:1;       // 定时器事件
    
    unsigned         cancelable:1;  // 是否可取消
};

/* 连接结构体 */
struct ngx_connection_s {
    void               *data;
    ngx_event_t        *read;       // 读事件
    ngx_event_t        *write;      // 写事件
    
    ngx_socket_t        fd;         // socket fd
    
    ngx_recv_pt         recv;       // 接收函数
    ngx_send_pt         send;       // 发送函数
    ngx_recv_chain_pt   recv_chain;  // 接收链
    ngx_send_chain_pt   send_chain;  // 发送链
    
    ngx_listening_t    *listening;  // 所属的 listening
    
    off_t               sent;       // 已发送字节数
    
    ngx_log_t          *log;
    
    void               *pool;       // 内存池
    
    int                 number;     // 连接编号
    
    unsigned            buffered:1; // 是否缓冲
    
    unsigned            shared:1;   // 是否共享
};

5.3 HTTP 请求处理流程

是

否

否

是

是

否

accept 新连接

ngx_get_connection

ngx_add_conn
添加到epoll

数据可读?

ngx_http_wait_request_handler

继续等待

解析 HTTP 请求

解析完成?

ngx_http_process_request

执行HTTP阶段

发送响应

Keep-Alive?

关闭连接

HTTP 阶段处理：

// src/http/ngx_http_request.c

void
ngx_http_process_request(ngx_http_request_t *r)
{
    ngx_connection_t  *c;

    c = r->connection;

    // 设置请求处理回调
    r->read_event_handler = ngx_http_block_reading;
    
    // 进入 HTTP 阶段处理
    ngx_http_handler(r);

    // 通知不需要再读取
    if (c->read->timer_set) {
        ngx_del_timer(c->read);
    }
    
    // 处理写事件
    if (ngx_handle_read_event(c->read, 0) != NGX_OK) {
        ngx_http_close_request(r, 0);
        return;
    }
}

static void
ngx_http_handler(ngx_http_request_t *r)
{
    ngx_http_core_main_conf_t  *cmcf;

    cmcf = ngx_http_get_module_main_conf(r, ngx_http_core_module);

    // 执行各个阶段
    r->main->count++;
    ngx_http_core_run_phases(r);
}

HTTP 11 个阶段：

阶段模块说明
NGX_HTTP_POST_READ_PHASE-读取请求后
NGX_HTTP_SERVER_REWRITE_PHASErewriteServer 级别 URL 重写
NGX_HTTP_FIND_CONFIG_PHASE-查找 location 配置
NGX_HTTP_REWRITE_PHASErewriteLocation 级别 URL 重写
NGX_HTTP_POST_REWRITE_PHASE-重写后处理
NGX_HTTP_PREACCESS_PHASElimit_req/limit_conn访问前限制
NGX_HTTP_ACCESS_PHASEaccess/auth权限检查
NGX_HTTP_POST_ACCESS_PHASE-权限检查后
NGX_HTTP_PRECONTENT_PHASEtry_files预内容处理
NGX_HTTP_CONTENT_PHASEproxy/fastcgi内容生成阶段
NGX_HTTP_LOG_PHASEaccess_log日志记录

6. 性能调优实战

6.1 核心配置参数详解

# nginx.conf 优化配置

user  nginx;
worker_processes  auto;           # 自动检测 CPU 核心数
worker_cpu_affinity auto;         # 绑定 CPU 亲和性
worker_rlimit_nofile 65535;       # 每个进程的最大文件描述符

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    use epoll;                    # 使用 epoll
    worker_connections 10240;     # 每个Worker的最大连接数
    accept_mutex on;              # 开启 accept_mutex
    accept_mutex_delay 100ms;     # 获取锁超时时间
    multi_accept on;              # 一次accept多个连接
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    # 日志格式
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    # 高性能优化
    sendfile        on;            # 使用 sendfile 零拷贝
    tcp_nopush      on;            # 优化数据包发送
    tcp_nodelay     on;            # 禁用 Nagle 算法
    keepalive_timeout  65;         # 长连接超时
    keepalive_requests 10000;      # 每个连接最大请求数

    # Gzip 压缩
    gzip on;
    gzip_min_length 1024;
    gzip_comp_level 6;
    gzip_types text/plain text/css text/xml text/javascript
               application/json application/javascript application/xml+rss;

    # 缓冲区优化
    client_body_buffer_size 128k;
    client_max_body_size 10m;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 4k;

    # 隐藏版本号
    server_tokens off;

    include /etc/nginx/conf.d/*.conf;
}

6.2 Worker 进程数优化

计算公式：

# 最佳 Worker 数量 = CPU 核心数
# 如果是 SSL 密集型：Worker 数量 = CPU 核心数 × 2

# 查看CPU核心数
lscpu | grep "^CPU(s)"

# 推荐
worker_processes auto;  # 自动适配

# 或手动指定
worker_processes 8;     # 8核CPU
场景worker_processes说明
静态文件服务CPU 核心数I/O 密集型，每个 Worker 处理大量连接
反向代理CPU 核心数网络 I/O 为主
SSL 终止CPU 核心数 × 2CPU 密集型（加密解密）
压缩处理CPU 核心数 × 1.5CPU 密集型

6.3 Worker 连接数优化

最大并发计算：

# 最大并发数 = worker_processes × worker_connections
# 示例：8 × 10240 = 81920

# 检查系统限制
ulimit -n  # 应该大于 worker_connections

# 临时调整
ulimit -n 65535

# 永久调整（/etc/security/limits.conf）
* soft nofile 65535
* hard nofile 65535

配置建议：

业务类型worker_connections说明
小型网站1024-4096低并发
中型网站4096-10240中等并发
大型网站10240-65535高并发
CDN/WAF65535+超高并发

6.4 性能对比测试

测试环境：

  • CPU: 8 核
  • 内存: 16GB
  • OS: Ubuntu 22.04 LTS
  • Nginx: 1.24.0

测试命令：

# 使用 ab (Apache Bench)
ab -n 100000 -c 1000 http://localhost/index.html

# 使用 wrk
wrk -t 8 -c 1000 -d 30s http://localhost/

性能对比：

配置QPSCPU 使用率内存占用延迟 (P99)
worker_processes=1, worker_connections=102412,00098%150MB45ms
worker_processes=4, worker_connections=409635,00085%400MB22ms
worker_processes=8, worker_connections=1024068,00078%750MB15ms
worker_processes=auto, worker_connections=1024072,00075%780MB14ms

结论：

  • ✅ worker_processes=auto 是最优选择
  • ✅ 增加连接数可以提升吞吐量，但内存也会增加
  • ✅ CPU 亲和性（worker_cpu_affinity）可提升 5-10% 性能

6.5 内核参数优化

# /etc/sysctl.conf

# 最大连接队列
net.core.somaxconn = 32768
net.ipv4.tcp_max_syn_backlog = 8192

# TIME_WAIT 优化
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

# TCP 缓冲区
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# 保持连接
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

# 应用配置
sysctl -p

7. 总结与展望

7.1 架构总结

Nginx 的高性能源于三大支柱：

Nginx 高性能

Master-Worker 模型

事件驱动机制

惊群效应解决

进程隔离

充分利用多核

平滑重启

epoll/kqueue

Reactor 模式

非阻塞 I/O

accept_mutex

EPOLLEXCLUSIVE

负载均衡

7.2 关键技术要点

技术点核心实现带来的优势
Master-Worker 模型多进程 + 进程隔离稳定性、容错性、多核利用
事件驱动Reactor 模式 + epoll高并发、低延迟、非阻塞
惊群解决方案accept_mutex + EPOLLEXCLUSIVE避免 CPU 浪费、提升性能
零拷贝技术sendfile + mmap减少内存拷贝、降低 CPU 占用
连接池keep-alive减少 TCP 握手开销

7.3 Nginx vs 其他 Web 服务器

特性NginxApache httpdCaddy
架构模型Master-Worker多进程/多线程协程
并发能力⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
静态文件性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
配置复杂度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
动态语言支持通过 FastCGI原生模块插件
HTTPS 自动化手动配置手动配置✅ 自动
反向代理⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

7.4 未来发展方向

  1. HTTP/3 支持：Nginx 1.25+ 已开始支持 QUIC 协议
  2. eBPF 集成：使用 eBPF 优化网络过滤和监控
  3. 云原生适配：增强 Service Mesh 和 Kubernetes 集成
  4. TLS 1.3：进一步优化加密连接性能
  5. 模块化生态：OpenResty、Tengine 等衍生版本

7.5 学习建议

深入 Nginx 的路径：

开始学习

基础配置

反向代理/负载均衡

性能调优

源码阅读

模块开发

内核优化

推荐资源：

  1. 官方文档：https://nginx.org/en/docs/
  2. 源码阅读：https://github.com/nginx/nginx
  3. 书籍：《深入理解 Nginx》、《Nginx 高性能 Web 服务器》
  4. 社区：https://forum.nginx.org/

结语

Nginx 的架构设计堪称教科书级别，它将 Master-Worker 模型的稳定性、事件驱动的高效性和精心设计的细节优化完美结合，实现了单机百万级并发的壮举。

通过本文的深度剖析，我们不仅理解了 Nginx 的工作原理，更重要的是学到了：

  • 如何设计高并发系统
  • 如何在多进程和事件驱动之间找到平衡
  • 如何解决实际工程中的惊群效应等问题

这些设计思想不仅适用于 Web 服务器，更可以推广到任何需要处理高并发 I/O 的系统中。

“简单是可靠的前提。” — Nginx 设计哲学

标签： Nginx 架构 Master-Worker 事件驱动 高性能 源码分析

作者： [您的名字]
来源： CSDN
原文链接： [待发布后填充]

版权声明： 本文为原创文章，转载请注明出处。

相关阅读：

标签
#Nginx #架构 #Master-Worker #事件驱动
Nginx工作原理（Master+Worker）
Kim_Weir的专栏
04-22 1万+
Nginx首先要明白，Nginx 采用的是多进程（单线程） &amp; 多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。多进程的工作模式1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。 2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。 3、 master 进程能监控 wo...
Apache与Nginx核心差异：进程模型、事件驱动与生产配置实践
weixin_30265103的博客
06-21 507
Web服务器是现代应用交付的基石，其底层架构直接决定并发能力、资源开销与运维韧性。Apache基于多进程/多线程MPM模型，强调模块深度集成与运行时稳定性，适合PHP嵌入式部署和强认证场景；Nginx则采用异步非阻塞事件驱动架构，以极低内存支撑高并发，依赖FastCGI等标准协议实现语言解耦。这种根本性设计差异，导致二者在HTTPS配置、反向代理健壮性、大文件上传（413错误）定位路径、Brotli压缩支持及配置容错机制上表现迥异。理解进程模型与事件循环原理，是规避502网关错误、if指令陷阱、SSL环境变
Nginx高并发原理
lzf的博客
01-24 1451
转载自：初步探索Nginx高并发原理首先要明白，Nginx 采用的是多进程（单线程） &amp; 多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。多进程的工作模式1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。 2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。 3、 ma...
深入解析Nginx高并发架构：从事件驱动到内存池的设计精髓
weixin_30298497的博客
08-07 465
在构建高并发Web服务时，事件驱动架构和异步非阻塞I/O是核心技术范式。其原理在于通过I/O多路复用机制（如Linux的epoll）管理大量连接，使单个进程能够高效处理成千上万的并发请求，从而解决经典的C10K问题。这种设计的技术价值在于最大化CPU利用率，避免进程或线程因阻塞而浪费资源，是实现高性能网关和反向代理的基石。其典型应用场景包括API网关、负载均衡器以及静态资源服务器等。本文聚焦于Nginx，这一领域的典范实现，通过剖析其Master-Worker进程模型和高效的内存池管理机制，揭示其如何将事件
nginx：什么是Nginx服务器的Master和Worker进程?分别有什么作用？
weixin_43290370的博客
04-24 1905
Nginx的Master-Worker架构是其高并发能力的基石，理解其内部机制对于构建高性能服务至关重要。Worker数量与CPU核心的最佳配比连接池和内存管理的精细化控制内核参数与网络协议栈的协同优化动态模块加载带来的扩展可能性掌握这些核心技术点，不仅能够应对大厂面试的深度拷问，更能为实际业务带来显著的性能提升和稳定性保障。
Nginx 事件驱动模型（master-worker 进程）
小飞的博客
03-02 1039
Nginx 事件驱动模型摘要 Nginx采用master-worker多进程架构解决C10K高并发问题。主进程负责管理，worker进程(数量通常等于CPU核数)通过epoll事件循环高效处理连接。每个worker使用非阻塞I/O同时处理数千连接，通过事件驱动机制在连接就绪时快速切换处理，避免线程/进程切换开销。相比传统Apache等每连接一进程模型，Nginx内存占用更低(10K并发约150MB)，吞吐量更高(静态文件达50K req/s)。该模型牺牲了单请求处理延迟换取高并发能力，适合作为反向代理、AP
master-worker模式以及几种实现
Michael_fchou的博客
05-31 2024
模型介绍 Master-Worker模式是常用的并行模式之一，它的核心思想是，系统有两个进程协作工作：Master进程，负责接收和分配任务；Worker进程，负责处理子任务。当Worker进程将子任务处理完成后，结果返回给Master进程，由Master进程做归纳汇总，最后得到最终的结果。 1.ZooKeeper中的master-worker实现 每个worker的监控与调度可以交给第三方工具去实现，比如Zookeeper便可以充当这样的角色，zookeeper是一个分布式文件系统，我们可以把work
nginx启动只有master没有worker_深入浅出Nginx
weixin_39737757的博客
11-27 956
点击上方“ 码农编程进阶笔记 ”，选择“置顶或者星标”文末有干货,每天定时与您相约！前言Nginx是一款轻量级的Web服务器、反向代理服务器，由于它的内存占用少(一个worker进程只占用10-12M内存)，启动极快，高并发能力强，在互联网项目中广泛应用。上图基本上说明了当下流行的技术架构，其中Nginx有点入口网关的味道。反向代理服务器经常听人说到一些术语，如反向代理，那么什么是反向代...
第一章【基石与起源】—— NGINX 架构设计与工作模式
qq_55902573的博客
12-14 856
Nginx采用模块化设计、异步非阻塞I/O等技术实现高并发。这种架构使Nginx具有出色的扩展性、可靠性和资源利用率。本节详细介绍了nginx的架构设计和工作模式
后端面试必备：深入理解Nginx服务器的Master和Worker进程
qq_58299462的博客
04-23 1067
Nginx采用了一种独特的多进程模型，由一个Master进程和多个Worker进程组成。这种设计使得Nginx能够高效处理大量并发连接，同时保持稳定性和可靠性。
Nginx 架构解密：master-worker 如何支撑百万并发？
最新发布
qq_52580914的博客
08-09 377
配置块作用范围全局块整个 nginx 实例events网络连接、并发参数http所有 http 协议、所有网站共用server单个虚拟主机（站点）location站点内部不同 URI 路径规则算法配置写法核心逻辑使用场景轮询不写任何策略请求依次分配后端性能差不多，无会话保持权重按权重比例分配后端性能不均ip_haship_hash;按客户端 TCP 源 IP 哈希，同一 IP 固定后端需要会话保持，无前置代理通用哈希hash $变量 [consistent];
8.Nginx 原理解析（Master+Worker）
自能生羽翼，何必仰云梯
07-19 1154
1、Nginx   首先要明白，Nginx 采用的是多进程（单线程） & 多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。 　　 2、多进程的工作模式   1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。   2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。   3、 master 进程能监控 worker 进程的运行状态，当 worker 进程退出后(异常情况下)，会自动
nginx启动只有master没有worker_Nginx 架构和基础原理
weixin_39622084的博客
12-23 740
Nginx 的应用场景Nginx 的应用场景主要有三个：静态资源服务反向代理服务API 服务静态资源服务Nginx 可以通过本地文件系统提供静态资源的服务，例如纯静态的 HTML 页面等。反向代理服务很多应用服务的运行效率是很低的，QPS，TPS，并发等都是受限的，所以需要把很多应用服务组成一个集群，向用户提供高可用性的服务，这个时候需要 Nginx 的反向代理功能，而应用服务的动态扩容需要负载均...
Nginx 从入门到精通：全面解析与实战指南
热门推荐
qq_59998784的博客
04-21 1万+
在高性能 Web 服务领域，Nginx 早已成为无可替代的核心组件。无论是中小网站的静态资源托管，还是大型互联网架构的反向代理与负载均衡，Nginx 都以其轻量、高效、稳定的特性占据着统治地位。本文将从基础认知出发，深入剖析 Nginx 的核心功能、架构原理、配置精髓与性能优化策略，助力开发者构建企业级的 Nginx 服务。
Nginx Worker ← 多进程模型，每个 worker 单线程 ，知识体系一共包含哪些部分及其详解？底层原理是什么？
长风破浪会有时的博客
09-20 876
✅ Nginx 采用主进程（Master） + 多个工作进程（Worker）的多进程模型，每个 Worker 进程是单线程、事件驱动、非阻塞 I/O的设计，利用操作系统级的epoll（Linux）或kqueue（BSD）实现高并发连接处理，用多进程避免锁竞争，用单线程+事件循环实现极致性能与稳定性。维度内容✅ 核心模型Master-Worker 多进程架构✅ Worker 特性单线程、事件驱动、非阻塞 I/O✅ 高性能根源。
Nginx事件驱动架构
u013257321的博客
02-07 1007
事件驱动架构（Event-driven Architecture，EDA）是一种通过事件来驱动系统行为的架构模式，广泛应用于高并发、高性能的应用场景。与传统的线程模型不同，事件驱动架构通过监听、捕获和响应事件来实现系统操作。在Nginx中，事件驱动架构使其能够高效地处理大量并发连接，避免了传统多线程模型中大量线程的创建与销毁所带来的性能开销。
深入解析Nginx高性能架构：Master-Worker模型与事件驱动机制
weixin_33965305的博客
08-07 514
在构建高并发Web服务时，事件驱动架构和I/O多路复用是核心技术基础。事件驱动模型通过单一控制流监听所有连接事件，避免了传统多线程模型因频繁上下文切换导致的性能瓶颈，其核心在于非阻塞处理和高效的事件循环机制。这一设计理念在Linux系统中通过epoll等系统调用实现，epoll利用内核回调机制和就绪列表，实现了O(1)时间复杂度的事件通知，大幅提升了海量连接下的处理效率。这些技术的工程价值在于以恒定资源消耗支撑数万并发连接，成为现代高性能服务器的基石。Nginx正是这一架构的典范实践，其Master-Wor
请解释Nginx服务器上的Master和Worker进程分别是什么?
wupanP的博客
07-24 1197
Nginx 服务器使用多进程架构，主要包括一个 Master 进程和多个 Worker 进程。每种进程都有不同的职责和功能，它们共同协作来处理客户端请求。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值