工作知识库

Appearance

本轮 服务器运维面试题库（带答案） ​

【面试题】1. Nginx 的 location 匹配规则有哪些？优先级是怎样的？ ​

【标准答案】Nginx 的 location 匹配有四种规则：

精确匹配 = /path — 优先级最高，匹配成功后直接返回，不再检查其他规则。适合配置首页或高频率接口。

前缀匹配（优先） ^~ /path — 匹配成功后不再检查正则规则。适合静态资源目录。

正则匹配 ~ 区分大小写、~* 不区分大小写 — 按配置文件中的顺序匹配，第一个匹配生效。适合 URL 重写、动态路由。

普通前缀匹配 /path — 优先级最低，正则匹配失败后才会使用。

面试要点：优先级顺序 = 精确 > ^~ > 正则 > 普通。实际配置中，把高频路径用 = 锁定，静态目录用 ^~ 提前截断，复杂路由用正则但注意顺序。

【面试题】2. Nginx 的 upstream 负载均衡策略有哪些？各自适用场景是什么？ ​

【标准答案】Nginx upstream 支持六种策略：

轮询（默认） — 逐一分配，适合后端服务器性能相近的场景。

权重 weight — server 192.168.1.10 weight=3; 按权重比例分配，适合配置不均的集群。

IP 哈希 ip_hash — 同一 IP 固定访问同一后端，适合需要会话粘性的场景（但不推荐，应改用 Redis 共享 Session）。

最少连接 least_conn — 请求发给当前连接数最少的服务器，适合长连接场景如 WebSocket。

fair（第三方） — 根据后端响应时间动态分配，响应快的多分配，适合对延迟敏感的业务。

URL 哈希 url_hash（第三方） — 同一 URL 请求固定后端，适合缓存服务器场景。

面试加分：配置健康检查 max_fails=3 fail_timeout=30s，自动剔除故障节点；生产环境推荐 fair + 权重组合。

【面试题】3. 如何排查 Nginx 502/503/504 错误？各是什么原因？ ​

【标准答案】三个错误都跟后端服务有关，但根因不同：

502 Bad Gateway — Nginx 能通但后端返回无效响应。常见原因：后端服务挂了、端口配错、协议不匹配（如配置了 proxy_pass 但后端是 WebSocket）。排查：systemctl status backend、netstat -tlnp | grep 端口、检查 upstream 配置。

503 Service Unavailable — 后端服务过载或维护中。常见原因：连接数超限、后端队列满了、熔断器打开。排查：netstat -an | grep ESTABLISHED | wc -l 看连接数、检查后端限流配置、查看应用日志是否有熔断告警。

504 Gateway Timeout — Nginx 等待后端响应超时。常见原因：后端处理慢、数据库慢查询、第三方接口超时。排查：增加 proxy_read_timeout 临时验证、查后端慢日志、strace -p PID 跟踪请求。

面试要点：502 查后端存活，503 查后端负载，504 查后端性能。先看 Nginx error.log 定位具体错误信息。

【面试题】4. Keepalived + Nginx 高可用方案的工作原理是什么？ ​

【标准答案】Keepalived 基于 VRRP 协议实现虚拟 IP（VIP）漂移，配合 Nginx 实现高可用：

架构：两台 Nginx 服务器互为主备，Keepalived 管理一个 VIP。主节点持有 VIP 提供服务，备节点待命。

故障切换流程：主节点的 Keepalived 健康检查发现 Nginx 挂了 → 降低自身优先级 → 广播 VRRP 通告 → 备节点收不到主节点通告或收到低优先级通告 → 夺取 VIP → 流量切换到备节点。

关键配置：

  • vrrp_script 定义健康检查脚本，检测 Nginx 进程存活
  • track_script 关联健康检查到 VRRP 实例
  • priority 主节点优先级高于备节点

面试加分：Keepalived 只检测 Nginx 进程，不检测业务健康。生产中配置 Nginx 主动健康检查，后端服务异常时 upstream 自动剔除。切换时间约秒级，对长连接业务有影响，需要客户端重连机制。

【面试题】5. Tomcat 的 Connector 线程模型 NIO/APR/NIO2 有什么区别？ ​

【标准答案】Tomcat Connector 支持三种线程模型：

BIO（已废弃） — 同步阻塞 IO，每个请求一个线程，并发能力差，Tomcat 8.5 后已移除。

NIO（推荐） — 基于 Java NIO，非阻塞 IO，用较少线程处理大量连接。Tomcat 8.5+ 默认。配置 <Connector protocol="org.apache.coyote.http11.Http11NioProtocol">。适合高并发短连接场景。

APR — 使用本地库 Apache Portable Runtime，性能最高，支持 OpenSSL 加速。需要安装 APR 和 Tomcat Native 库。配置 <Connector protocol="org.apache.coyote.http11.Http11AprProtocol">。适合性能要求极致的生产环境。

NIO2 — Java 7+ AIO 异步 IO，理论性能更好但实际提升有限，稳定性不如 NIO。

面试要点：一般项目用 NIO 即可；追求极致性能且能接受运维复杂度用 APR；NIO2 不推荐。调优时关注 maxThreads（最大工作线程）、acceptCount（等待队列长度）、maxConnections（最大连接数）。

【面试题】6. Linux 系统中如何排查 CPU 使用率过高的问题？ ​

【标准答案】CPU 飙高排查四步走：

第一步：确认是用户态还是内核态

bash
top -c  # 看 %us（用户态）和 %sy（内核态）

用户态高 → 应用代码问题；内核态高 → 系统调用频繁或驱动问题。

第二步：定位高 CPU 进程和线程

bash
top -H -p PID    # 查看进程的线程 CPU 占用
ps -mp PID -o THREAD,tid,time  # 线程级详情

第三步：导出线程栈分析

bash
jstack PID > thread.log   # Java 应用
pstack PID                # C/C++ 应用

将 top 中的高 CPU 线程 ID 转为 16 进制，在栈日志中搜索对应 nid，定位到具体代码行。

第四步：专项分析

  • 死循环 → 代码审查循环逻辑
  • GC 频繁 → jstat -gc PID 1000 查看 GC 频率
  • 上下文切换 → vmstat 1 看 cs（context switch）列

面试加分：配合 perf top 或 async-profiler 做热点分析；生产环境提前配置 JMX 远程监控，出问题时直接 VisualVM 分析。

【面试题】7. 如何设计一个百万级并发的高可用服务器架构？ ​

【标准答案】百万级并发需要分层架构设计：

接入层：

  • DNS 轮询实现多机房入口
  • LVS + Keepalived 四层负载均衡，支持百万级连接
  • Nginx 七层负载，做 SSL 卸载、路由分发

服务层：

  • 微服务拆分，核心服务独立部署
  • 服务注册发现（Nacos/Consul）
  • 限流熔断降级（Sentinel/Hystrix）

数据层：

  • 读写分离，主库写、从库读
  • 分库分表（ShardingSphere）水平扩展
  • 多级缓存：本地缓存 → Redis 集群 → 数据库

存储层：

  • 热数据 Redis 集群（Codis/Twemproxy）
  • 冷数据归档到对象存储
  • 消息队列削峰（Kafka/RocketMQ）

关键优化点：

  • 连接池复用，避免频繁建连
  • 异步非阻塞，Netty/Go 协程
  • 无状态服务，方便水平扩展
  • 熔断降级，保护核心链路

面试加分：提到全链路压测、混沌工程、异地多活、柔性事务、服务网格 Service Mesh 都是加分项。

【面试题】8. Prometheus + Grafana 监控体系的核心组件和采集流程是什么？ ​

【标准答案】Prometheus 是时序数据库 + 监控系统，Grafana 是可视化平台：

核心组件：

  • Prometheus Server — 数据采集和存储引擎
  • Exporter — 数据采集代理，暴露 /metrics 接口（如 node_exporter 采集主机指标，mysqld_exporter 采集 MySQL）
  • Pushgateway — 短生命周期任务的指标推送中转站
  • Alertmanager — 告警去重、分组、路由
  • Grafana — 可视化仪表盘

采集流程：

  1. Prometheus 定时拉取（Pull 模式）各 Exporter 的 /metrics 接口
  2. 数据存入本地时序数据库（TSDB）
  3. Grafana 配置 Prometheus 数据源，通过 PromQL 查询展示
  4. Alertmanager 接收 Prometheus 告警，分发到邮件/钉钉/企微等渠道

PromQL 示例：

promql
rate(http_requests_total[5m])  # 5分钟请求速率
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100  # 内存可用百分比

面试加分：Pull 模式优势是服务端控制采集频率，避免客户端推送导致服务端过载。生产中配置服务发现（Kubernetes SD / Consul SD）自动发现监控目标。

【面试题】9. Docker 容器资源限制如何配置？不限制会有什么问题？ ​

【标准答案】Docker 通过 cgroups 实现资源限制：

CPU 限制：

bash
docker run --cpus=1.5 nginx      # 限制使用 1.5 个 CPU
docker run --cpu-shares=512 nginx  # 相对权重（默认1024）
docker run --cpuset-cpus="0,1" nginx  # 绑定到 CPU 0 和 1

内存限制：

bash
docker run -m 2g --memory-swap=4g nginx  # 内存2G，总内存+swap 4G
docker run --memory-reservation=1g nginx  # 软限制，内存紧张时回收

磁盘 IO 限制：

bash
docker run --device-read-bps=/dev/sda:10mb nginx  # 读速率限制
docker run --device-write-iops=/dev/sda:100 nginx  # 写 IOPS 限制

不限制的问题：

  • 单个容器耗尽宿主机 CPU，导致其他容器和系统进程卡顿
  • 内存泄漏容器触发 OOM Killer，可能误杀系统关键进程
  • IO 密集型容器抢占磁盘带宽，影响数据库等 IO 敏感服务
  • 容器逃逸风险更高，攻击者可利用资源耗尽做 DoS 攻击

面试加分：Kubernetes 中用 resources.requests 和 resources.limits 分别设置申请量和限制量。requests 用于调度决策，limits 用于运行时限制。生产中必须配置 Limits 防止资源争抢。

【面试题】10. 服务器被入侵后如何应急响应？ ​

【标准答案】入侵应急响应七步流程：

第一步：隔离止损

  • 断网或隔离主机，防止横向扩散
  • 保留现场，不要立即重启

第二步：排查入侵途径

  • 检查开放端口 netstat -tunlp
  • 检查可疑进程 ps auxf、top
  • 检查定时任务 crontab -l、/etc/cron*
  • 检查启动项 systemctl list-unit-files、/etc/rc.local
  • 检查 SSH 登录 last -n 20、/var/log/secure

第三步：溯源分析

  • 检查 Web 日志 /var/log/nginx/access.log，搜索 SQL 注入特征
  • 检查系统日志 /var/log/messages、/var/log/syslog
  • 检查用户账户 cat /etc/passwd，查找异常 UID 0 账户
  • 检查最近修改文件 find / -mtime -1 -type f

第四步：清理后门

  • 删除恶意账户
  • 删除定时任务
  • 杀掉恶意进程
  • 删除可疑文件（Webshell、挖矿程序）

第五步：修复漏洞

  • 升级有漏洞的软件版本
  • 修复弱口令
  • 配置防火墙策略
  • 打补丁

第六步：加固防护

  • 部署 Fail2ban 防暴力破解
  • 配置 WAF 防护
  • 开启日志审计
  • 增加入侵检测系统（HIDS）

第七步：复盘总结

  • 编写事件报告，记录时间线、影响范围、根因
  • 制定改进措施，防止再次发生

面试加分：提到 SOC（安全运营中心）、EDR（端点检测响应）、零信任架构是加分项。生产中应有入侵演练和自动化响应预案。