【视频笔记】Nginx是什么？Nginx高并发架构拆解指南
多个后端服务器时，前端不知道找哪个机器，就需要一个中间进程来做流量转发和分发（负载均衡）
屏蔽掉后面具体有哪些服务器的代理方式，就是常说的反向代理
有了反向代理，我们对外就可以只提供一个URL域名，背后根据需要，随时扩缩容服务
这个反向代理的程序，刚好可以加到前面放html文件的进程上（http服务器）
前后端网络流量都要经过这个中间进程，那也算是一个网关了，那就再加上一些通用的网关能力：
加日志, 记录每次调用的结果，方便后面排查问题
对输入输出加入压缩的功能，减小网络带宽消耗
对某个ip进行限流或封禁
对输入输出的内容进行修改
提供用户自定义功能，来实现特定功能
协议：
已支持http，还可以支持tcp、udp、http2、websocket
这些能力，可以让用户来选择用哪些，于是可以加个配置文件，也就是nginx.conf
现在这个网关进程的主要任务，就是跟上下游建立网络连接，顺便内部做下处理
多个客户端请求，通过网络进入到一个进程，如果用多线程并发处理，那就需要考虑并发问题影响性能
怎么办？ 外部请求都塞到一个线程上处理
将单个进程换成多个进程，管他们叫worker进程
用多个worker进程，同时监听一个ip地址加端口，一有流量进来，操作系统就会随机给到其中一个进程处理
将进程数量设置为跟操作系统cpu核数一致，那每个进程都能得到一个核
问题1 ：用多个worker进程，同时监听一个ip地址加端口，这里为什么不会端口冲突？
上面多个worker进程模型，流量被分到多个worker进程，要限流的话，每一个worker进程要单独计数，那还怎么限流
给多个进程，分配一块共享内存，使多个进程能够基于相同一份数据做计算
proxyCache
一些用户请求可以在前期访问后端服务器之后，缓存在网关，后面再访问，可以直接返回缓存的数据。 用磁盘空间，换取网络传输或CPU计算耗时
需要一个协调进程，协调worker进程谁先谁后，比如worker进程滚动升级等，这个协调进程就是master进程
master进程读取nginx.conf配置，统一管理多个worker
最开始那个单进程的网关服务，演变为具有上述丰富功能的网关服务，他就是nginx
做好相关配置，性能5万QPS轻松应付
问题2： 现在它还只是一台服务器上的多个进程，服务器跪了，nginx也就跪了，成了单点问题，怎么解决呢？ nginx有集群模式吗？
一些评论
一、Nginx 架构核心设计总结
1. 基础功能定位
- HTTP 服务器：直接提供静态资源（HTML/CSS/JS），支持高效的文件传输
- 反向代理：接收客户端请求并转发至后端服务集群，实现负载均衡
- 模块化网关：通过插件机制扩展功能（如限流、缓存、SSL 终止等）
2. 核心架构特性
- 单线程异步非阻塞：基于事件驱动模型，一个线程处理所有 IO 事件，避免上下文切换开销
- Master-Worker 进程模型：
- Master 进程：管理 worker 进程生命周期，负责配置热加载和滚动升级
- Worker 进程：实际处理请求，数量通常等于 CPU 核心数，独立监听同一端口（通过 SO_REUSEADDR 实现）
- 共享内存机制：用于存储计数器（如限流）、缓存元数据等全局状态
- Proxy Cache：将后端响应缓存到磁盘，降低后端负载（需配置 proxy_cache_path）
3. 关键设计优势
- 高性能：5 万 QPS + 处理能力（静态资源场景）
- 高可靠性：worker 进程独立，单进程崩溃不影响整体服务
- 灵活性：通过配置文件（nginx.conf）实现功能组合，支持动态加载模块
二、单点故障问题分析
问题描述：
当 Nginx 所在服务器宕机时，所有依赖其代理的服务将不可用，形成单点故障。
解决方案：
通过高可用（HA）架构消除单点风险，常见方案如下：
- 主备模式（Keepalived + VRRP）
- 部署两个 Nginx 实例（主 + 备）
- Keepalived 监控主节点状态，通过 VRRP 协议实现虚拟 IP（VIP）漂移
- 优点：简单可靠，成本低
- 缺点：备节点资源闲置，切换时短暂中断
- 负载均衡集群（Nginx + 负载均衡器）
- 前端部署硬件负载均衡器（如 F5）或软件负载均衡器（如 HAProxy）
- 后端多个 Nginx 实例组成集群，负载均衡器按策略分发流量
- 优点：实现流量分担和故障转移
- 缺点：增加架构复杂度
- DNS 轮询
- 同一域名解析到多个 Nginx 实例 IP
- 客户端通过 DNS 返回的 IP 列表进行请求分发
- 优点：无需额外硬件 / 软件
- 缺点：负载均衡效果差，无法感知节点状态
- 服务网格（如 Istio）
- 在 Kubernetes 环境中，通过服务网格实现 Nginx 实例的自动发现和流量管理
- 优点：动态扩缩容，故障自愈能力强
- 缺点：需容器化环境支持
三、架构优化建议
- 配置优化
- nginx
worker_processes 4; # 与CPU核心数一致
events {
worker_connections 1024;
use epoll; # Linux高效事件驱动
}
http {
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m max_size=1g;
proxy_cache_valid 200 302 1h;
}
- 监控与报警
- 监控指标：QPS、延迟、错误率、连接数
- 工具推荐：Prometheus + Grafana
- 动态扩展
- 结合 Kubernetes 实现 Nginx 实例的自动扩缩容
- 使用 Ingress Controller 管理入口流量
四、总结
Nginx 通过单线程异步模型和Master-Worker 架构实现了高性能与灵活性的平衡，但单点故障需通过高可用方案解决。根据业务规模选择合适的 HA 架构：
- 中小规模：Keepalived 主备模式
- 大规模：负载均衡集群 + 服务网格
- 容器化环境：Kubernetes Ingress + Service Mesh
通过上述方案，可将 Nginx 的可用性提升至 99.99% 以上，满足大多数生产环境需求。
http { server { # 监听 80 端口，并启用 SO_REUSEPORT listen 80 reuseport; # IPv4 listen 【::】:80 reuseport; # IPv6 # 其他配置（如 server_name、location 等） server_name example.com; ... } }
投幣點讚了 想要說一下 在 bare metal 上面強調高併發是沒有意義的，physical I/O 決定了一切 throughput 因為任何服務在沒有 isolation（隔離性）的情況下 concurrency（併發）都是不可用(不可靠)的 在bare metal的情況下除非整台服務器只跑nginx一個服務，這樣調整worker master 達成並發才有意義 但是現代k8s啟蒙下 caddy, traefik 這些 golang based reverse proxy 經過一些調整在單台服務器上幾乎不會跟 nginx 有太多差別之外 在多台服務器配置上比nginx 要方便太多了 HAProxy Nginx 已經是上個時代的產物了，雖然他穩定高效 架不住 cilium 等現代 CNI + Cloud Native 服務快又方便啊
-- 在K8S中，CNI模型有哪些? - 黄嘉波 - 博客园
浙公网安备 33010602011771号