在当前的互联网技术面试中，nginx负载均衡面试题几乎是后端开发、运维工程师以及架构师岗位的必考题。随着微服务架构和容器化技术的普及，Nginx作为高性能的HTTP和反向代理服务器，其地位愈发重要。面试官不仅关注你是否会配置Nginx，更关注你对负载均衡算法、七层与四层代理区别、高可用架构设计以及底层性能调优的理解深度。本文将为您梳理最核心的面试题，并结合实际场景提供深度解答。
负载均衡（Load Balancing）是一种计算机技术，用于在多个计算机、计算机集群、网络连接、磁盘或其他资源之间分配工作负载。其目的是优化资源使用、最大化吞吐量、最小化响应时间，并避免任何单一资源的过载。在Nginx的语境下，它主要扮演反向代理服务器的角色，将客户端的请求分发到后端的多个Web服务器上。
这是面试中极高频的问题。理解两者的区别是掌握Nginx的关键。
| 特性 | 四层负载均衡 (L4) | 七层负载均衡 (L7) |
|---|---|---|
| OSI模型 | 传输层 (TCP/UDP) | 应用层 (HTTP/HTTPS) |
| Nginx模块 | stream 模块 | http 模块 |
| 判断依据 | IP地址和端口号 | URL、Header、Cookie等 |
| 适用场景 | 数据库代理、Redis代理、游戏服 | Web服务、API网关、动静分离 |
| 性能开销 | 较低 | 较高 (需解析HTTP包) |
在回答nginx负载均衡面试题时，列举并解释算法是基础。Nginx支持的算法包括：
Nginx采用Master-Worker的多进程架构。Master进程负责管理Worker进程，如接收信号、重新加载配置等。Worker进程则负责处理实际的网络请求。这种设计充分利用了多核CPU的优势，且Worker进程之间是独立的，一个Worker崩溃不会影响其他Worker。
Nginx使用异步非阻塞的事件驱动模型。在Linux下，它通常使用epoll机制。当有连接请求时，epoll会通知Nginx，Nginx唤醒一个空闲的Worker进程来处理该连接。这种模型在高并发场景下表现优异，能够支撑数万甚至数十万的并发连接。
Worker进程不需要等待IO操作完成，可以在等待期间处理其他连接，极大提高了资源利用率。
通过keepalive机制，Nginx与后端服务器保持长连接，减少了TCP三次握手和四次挥手的开销。
支持热部署，在不中断服务的情况下升级Nginx版本或修改配置。
这是最基础的配置，面试官常要求手写。以下是一个标准的反向代理配置示例：
server {
listen 80;
server_name www.example.com;
location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
注意：必须设置 proxy_set_header 以将客户端的真实IP传递给后端服务器，否则后端日志记录的将是Nginx的IP。
动静分离是Nginx的经典应用场景。将静态资源（图片、CSS、JS）由Nginx直接处理，动态请求（PHP、Java、Go）转发给后端应用服务器。
server {
listen 80;
server_name www.example.com;
# 静态资源直接由Nginx返回
location ~ .\.(gif|jpg|jpeg|png|bmp|swf|css|js)$ {
root /usr/share/nginx/html/static;
expires 30d;
access_log off;
}
# 动态请求转发
location / {
proxy_pass http://backend_servers;
}
}
针对不同业务场景，选择合适的负载均衡策略至关重要。以下是几种典型场景的配置方案：
当后端应用没有使用Redis等外部存储共享Session时，必须保证同一用户的请求始终路由到同一台服务器。
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
注意：ip_hash会导致负载不均，如果后端服务器宕机，需要手动配置或结合其他机制处理。
如果后端服务器内容一致且需要提高缓存命中率，可以使用url_hash。
upstream backend {
hash $request_uri;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
url_hash能确保相同的URL总是被分发到相同的服务器，从而最大化缓存命中率。
如果后端服务器配置不同，或者处理任务类型不同（如有的负责计算，有的负责IO），建议使用least_conn。
upstream backend {
least_conn;
server 192.168.1.10:8080 weight=5;
server 192.168.1.11:8080 weight=1;
}
结合weight使用，既能考虑当前连接数，又能体现服务器性能差异。
单点故障是系统的大忌。如果Nginx主节点宕机，整个服务将不可用。因此，生产环境通常采用主备（Master-Slave）或主主（Master-Master）模式。
最常用的方案是Keepalived。Keepalived通过VRRP协议实现虚拟IP（VIP）的漂移。当主节点宕机时，备节点接管VIP，提供服务。
在主备节点安装Nginx和Keepalived，确保Nginx配置一致。
主节点priority设高（如100），备节点设低（如90）。配置vrrp_script检测Nginx进程状态。
模拟主节点宕机，观察VIP是否成功漂移到备节点，业务是否中断。
脑裂是指主备节点都能检测到对方宕机，导致双方都抢占VIP，引发数据冲突。解决方法包括设置心跳线、使用脚本监控网络连通性等。
在生产环境中，合理的参数配置能显著提升Nginx的性能。以下是关键参数详解：
Nginx内置了强大的缓存功能。通过配置proxy_cache，可以将后端响应缓存到本地磁盘，大幅减轻后端压力。
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
proxy_cache_valid 200 30d;
proxy_cache_valid 404 1m;
add_header X-Cache-Status $upstream_cache_status;
proxy_pass http://backend;
}
}
通过检查响应头 X-Cache-Status，可以直观看到缓存命中情况（HIT/MISS）。