Nginx是大型架构核心，下面我详解Nginx百万连接@mikechen
核心模型：Epoll 的“降维打击”
Linux 下的 epoll 提供了高效的事件驱动机制，避免了传统 select/poll 随连接数线性增长的开销。
Nginx 采用 Reactor 模型，将大量连接的 I/O 事件抽象为可监听的事件集合。
当事件就绪时，内核一次性返回就绪列表，应用只需遍历就绪项进行处理。
从而把“高维度”的并发连接调度问题，降为单次遍历就绪集合的低开销操作。
这种“降维”使得在连接数激增时，事件分发与处理的 CPU 开销保持可控。
内存神技：零拷贝（Zero-Copy）
数据在用户态、与内核态之间的拷贝是性能瓶颈。
Nginx 通过利用 sendfile等内核接口，实现零拷贝传输。
数据在内核缓冲区和网卡 DMA 之间移动，无需多次在用户态与内核态间复制，显著降低 CPU 占用与内存带宽消耗。
配合合适的缓冲策略与异步 I/O，零拷贝将网络吞吐与延迟优化到接近硬件极限。
多路复用的“指挥官”：进程模型
Nginx 采用 master-worker 进程模型：master 进程负责读取配置与管理生命周期，worker 进程负责处理网络 I/O。
每个 worker 使用单线程事件循环（event loop），配合 epoll 处理大量连接，避免线程切换与锁竞争带来的开销。
通过合理配置 worker 数量与绑定 CPU，Nginx 能实现负载均衡的多核利用，且通过平滑重启与热升级机制保证服务可用性。
突破系统极限：内核参数调优
要支撑百万连接，单靠应用层优化不足，需调整内核参数以消除系统瓶颈。
常见措施包括提升文件描述符上限（ulimit 与 fs.file-max）、调整 epoll/网络相关缓冲大小。
ulimit -n：单进程可打开的最大 fd 数。
/proc/sys/fs/file-max：整个系统 fd 上限。
Nginx 自身的 worker_connections：要和系统 fd 上限配合，公式大致是：
单 worker 最大连接数 ≈ worker_connections。
再乘以 worker_processes 数量，才能达到更大连接规模。