运维八股文

🚀 运维八股文 · 高频速背手册

**方向：云原生运维 / SRE / DevOps

用法：每题做到"30 秒能讲清要点、2 分钟能展开"。先遮住答案自己讲一遍，卡壳的地方标记 ⭐ 反复背。

图例：📌 超高频必背 ｜ ✅ 已在《秋招模拟面试-问答整理》里练过详细版 ｜ 💡 记忆口诀

---

📚 模块地图

模块	内容	题号
一、计算机网络	握手挥手 / HTTP / DNS / 代理 / 状态码	N1--N10
二、操作系统	进程线程 / 死锁 / 内存 / IPC	O1--O7
三、Linux 运维	排查命令 / 权限 / systemd / 文本处理	L1--L9
四、Docker 容器	镜像分层 / 隔离 / 网络 / Dockerfile	D1--D10
五、Kubernetes	组件 / 控制器 / Service / 调度 / 探针	K1--K14
六、MySQL 速背	索引 / 事务 / 日志 / 主从（详见详细版）	M1--M9
七、中间件与工具	Redis / Nginx / Ansible / Git / Shell	R/NG/A/G/SH
八、场景题精选	排障思路（无标准答案，考逻辑）	SC1--SC7

---

模块一 ｜ 计算机网络

N1｜TCP 三次握手 & 四次挥手 📌（✅ 详细版见主文档）

答：

• 三次握手：① 客户端发 SYN（我要连你）；② 服务端回 SYN+ACK（收到，我也要连你，一个包合并）；③ 客户端回 ACK（确认）。之后才传数据。
• 为什么不是两次：防止"失效的旧连接请求"突然到达，服务端误建连接白等资源；第三次 ACK 是让服务端确认客户端真的准备好了。
• 四次挥手：① 主动方发 FIN（我说完了）；② 被动方回 ACK（收到，但我还有数据要发）；③ 被动方发 FIN（我也说完了）；④ 主动方回 ACK。因为 TCP 是全双工，两个方向要各自关闭，所以比握手多一次。
• 为什么等 2MSL：① 保证最后一个 ACK 能到（丢了对方会重发 FIN）；② 让本连接的老报文在网络里全部消失，避免污染新连接。
• 💡 记：握手"你/我/好"，挥手"两两道别"，全双工所以要四次。

N2｜TCP vs UDP 📌（✅ 详细版见主文档）

• TCP：面向连接、可靠（确认/重传/排序）、有流量与拥塞控制、慢；用于文件传输、网页、数据库。
• UDP：无连接、不可靠、只管发、快、低延迟；用于视频通话、直播、DNS、游戏。
• 💡 记：TCP 像"挂号信"，UDP 像"广播喇叭"。

N3｜HTTP vs HTTPS / TLS 握手 📌（✅ 详细版见主文档）

• 核心区别：HTTP 明文（可被窃听/篡改），HTTPS = HTTP + TLS 加密 + 身份认证。默认端口 80 vs 443。
• TLS 握手简版：① 客户端说支持的加密套件 → ② 服务端回证书（含公钥）→ ③ 客户端验证证书（CA 信任链、域名、有效期）→ ④ 客户端生成对称密钥，用服务器公钥加密发给服务端 → ⑤ 之后用对称密钥加密通信（性能好）。
• 为什么混合加密：非对称只用来安全地协商密钥，数据量大用对称加密更快。
• 💡 记：公钥加密传"钥匙"，之后对称加密传"货"。

N4｜HTTP 1.0 / 1.1 / 2.0 / 3.0 区别 📌

• 1.0：短连接，一次请求一次 TCP。
• 1.1：默认长连接（keep-alive）、支持 Host 头（一台服务器多域名）、管线化（但队头阻塞）。
• 2.0：二进制分帧、多路复用（一个连接并发多个请求，解决队头阻塞）、头部压缩 HPACK、服务端推送。
• 3.0：基于 UDP 的 QUIC，连接建立更快（0/1-RTT）、彻底解决队头阻塞、连接迁移不断线。
• 💡 记：1.0 连一次断一次 → 1.1 能复用 → 2.0 一条路多辆车 → 3.0 换飞机（UDP）。

N5｜TCP 怎么保证可靠 + 粘包怎么办 📌

• 可靠四板斧：① 确认应答 ACK；② 超时重传；③ 序号/去重/排序；④ 滑动窗口（流量控制）+ 拥塞控制（慢启动/拥塞避免/快重传快恢复）。
• 粘包原因：TCP 是字节流，没有消息边界，多个包粘在一起。
• 解决：应用层自己定边界------固定长度 / 分隔符（如 \n）/ 长度字段（包头带 body 长度）。
• 💡 记：可靠靠"确认+重传+序号"，粘包靠"应用层划边界"。

N6｜DNS 解析流程 📌（✅ 详细版见主文档）

• 浏览器缓存 → 操作系统缓存 / hosts → 本地 DNS 服务器（递归）→ 根服务器指路 → 顶级域（.com）→ 权威服务器 → 返回 IP 并逐级缓存。
• 💡 记：从近到远问路：自己 → 小区保安 → 总机 → 各层"管事的"。

N7｜HTTP 状态码速查 📌（✅ 详细版见主文档）

• 1xx：继续/握手（101 升级 WebSocket）。
• 2xx：200 成功；201 创建。
• 3xx：301 永久重定向；302 临时重定向；304 缓存未修改。
• 4xx：400 参数错；401 未认证；403 无权限；404 资源不存在；429 请求太频繁。
• 5xx：500 服务端内部错；502 网关收到上游无效响应（上游挂了/没起来）；503 服务暂时不可用（过载/维护）；504 网关超时（上游没在规定时间返回）。
• 💡 排障顺口溜：502 是"上游没起来"，503 是"忙不过来"，504 是"等太久超时"。

N8｜正向代理 vs 反向代理 / 四层 vs 七层 📌

• 正向代理：替"客户端"访问，客户端知道代理存在（翻墙、缓存、公司上网管控）。
• 反向代理：替"服务器"接收流量，客户端不知道后端存在（Nginx/Ingress，负载均衡 + 安全）。
• 四层（LVS/LB）：看 IP+端口转发，快、不解析内容。
• 七层（Nginx/HAProxy HTTP）：看 URL/Host/Header 路由，能做更细的策略、HTTPS 卸载。
• 💡 记：正向代理"代客买东西"，反向代理"前台接待分诊"。

N9｜Cookie vs Session vs Token 📌

• Cookie：存在浏览器的小数据，每次请求自动带上，可被篡改。
• Session：存在服务器（内存/Redis），靠 sessionId 关联，服务端有状态，多机要共享（粘性会话或 Redis）。
• Token/JWT：服务器签名后交给客户端，无状态，多机不用共享；JWT 缺点：不好主动吊销、有体积。
• 💡 记：Cookie 是"出入证放身上"，Session 是"登记在柜台"，Token 是"盖了章的自证"。

N10｜HTTPS 证书链 & 自签证书

• 证书链：根 CA → 中间 CA → 服务器证书；浏览器只信任内置根 CA，逐级验证签名。
• 自签证书：自己当 CA 签发，浏览器不认（提示不安全），实验/内网可加信任，生产用 Let's Encrypt / 企业 CA。
• 项目中：ingress 配 TLS，证书放 Secret，域名用 /etc/hosts 或内网 DNS 模拟。
• 💡 别吹：面试说清楚"实验环境自签 + hosts 模拟域名"，别冒充公网生产。

---

模块二 ｜ 操作系统

O1｜进程 vs 线程 vs 协程 📌

• 进程：资源分配的基本单位，独立内存空间，隔离好、切换重、通信要 IPC。
• 线程：CPU 调度的基本单位，同进程内共享内存，切换轻，但要加锁防竞争。
• 协程：用户态自己调度的"轻量线程"，一个线程里跑多个协程，切换极轻（函数级），适合 IO 密集（如 Go/nginx 高并发）。
• 💡 记：进程=独栋别墅，线程=合租房（共享客厅），协程=一间房里的流水线工人。

O2｜进程状态 / 僵尸进程 / 孤儿进程 📌

• 状态：运行 R、睡眠 S（可中断）/D（不可中断，等 IO）、停止 T、僵尸 Z。
• 僵尸进程：子进程结束但父进程没回收（没调用 wait），残留 PCB；父进程一直不回收就会积累，占进程表。
• 孤儿进程：父进程先死，子进程被 init/systemd（PID 1）收养并回收，所以孤儿一般无害。
• 排查：ps -ef | grep defunct / top 看 Z；处理：找父进程，重启父进程让 init 回收。
• 💡 记：僵尸是"死了没人收尸"，孤儿是"爹没了被国家收养"。

O3｜进程间通信 IPC 方式 📌

• 管道 pipe（有血缘关系、单向）、命名管道 FIFO（任意进程）。
• 信号 signal（kill -9 等）。
• 消息队列（有格式的消息）。
• 共享内存（最快，需配合信号量同步）。
• 信号量（锁/计数，解决互斥与同步）。
• Socket（不同机器也能通，最通用）。
• 💡 记：传话用管道、打暗号用信号、递纸条用队列、共用黑板用共享内存+信号量、跨省用 Socket。

O4｜死锁四条件 & 怎么破 📌

• 四个必要条件：① 互斥（资源一次一个进程用）；② 占有且等待；③ 不可剥夺；④ 循环等待。
• 破坏：锁按固定顺序拿（破循环）；一次拿所有锁（破占有等待）；超时放弃（破不可剥夺）。
• 数据库死锁：事务 A 锁 A 等 B，事务 B 锁 B 等 A → InnoDB 检测到会回滚其中一个事务。
• 💡 记：四条件"互斥、占有、不抢、成环"，破环最实用。

O5｜用户态 vs 内核态 & 系统调用 📌

• 内核态：能执行特权指令、直接操作硬件（内存、磁盘、网卡）。
• 用户态：应用程序只能在自己空间跑，想碰硬件/资源必须通过系统调用（read/write/open/socket...）陷入内核。
• 上下文切换：CPU 从一个进程切到另一个，要保存/恢复寄存器、页表等，有开销；线程切换比进程轻（不换地址空间）。
• 💡 记：用户态"坐办公室"，内核态"进机房"，进门要走系统调用这个"门禁"。

O6｜虚拟内存 / 分页 / Swap 📌

• 虚拟内存：每个进程看到独立的连续地址空间，由 MMU+页表映射到物理内存，隔离 + 能跑比物理内存大的程序。
• 分页：内存按 4KB 页管理；缺页时从磁盘换入。
• Swap：内存不够时把不用的页换到磁盘交换分区；Swap 频繁抖动说明内存不足（该加内存或查泄漏）。
• 排查：free -h 看 available；swap 使用率高 + si/so 大 → 内存压力大。
• 💡 记：虚拟内存是"每个进程都以为独占一套房"，Swap 是"东西多到放仓库"。

O7｜内存泄漏 / 内存溢出（OOM）怎么排查 📌

• 泄漏：申请了没释放，越积越多（Java 堆、C 指针、容器缓存）。
• 溢出：内存不够直接 OOM（进程被杀 / Pod OOMKilled）。
• 排查链路：free -h 看可用 → top 按内存排序找进程 → 看进程 RSS 是否持续上涨 → 应用日志/堆栈（Java 用 jstat/jmap 分析 dump）→ 容器看 limit 是否设太小 + 退出码 137。
• 💡 记：先看谁在吃，再看是否一直涨，最后看是不是被杀。

---

模块三 ｜ Linux 运维

L1｜排查命令全家桶 📌（✅ 详细版见主文档）

• CPU：top（按 P 排序）、mpstat、pidstat 定位线程。
• 内存：free -h（重点看 available）、top 按 M 排序。
• 磁盘：df -h（空间）、df -i（inode）、du -sh *（找大目录）。
• 端口/连接：ss -tlnp 或 netstat -tlnp；看连接数 ss -s。
• 进程：ps -ef | grep xxx、top -Hp PID 看线程。
• 负载：uptime（load 1/5/15）、vmstat 1（r 运行队列、si/so 换页）、iostat -x（磁盘 util/await）。
• 💡 记：CPU 用 top，内存 free，磁盘 df/du，端口 ss，进程 ps，整体负载 vmstat。

L2｜软链接 vs 硬链接 📌（✅ 详细版见主文档）

• 软链接：相当于快捷方式，存的是"目标路径"，有自己的 inode；目标删了链接失效（红/断链）；可跨文件系统、可链接目录。
• 硬链接：多个名字指向同一个 inode（同一份数据），只有所有链接都删了数据才释放；不能跨文件系统、不能链目录。
• 命令：软 ln -s；硬 ln。
• 💡 记：软链接"指向门牌"，硬链接"同一套房多把钥匙"。

L3｜文件权限 / SUID 📌

• rwx 对应数字 4/2/1；755=rwxr-xr-x；644=rw-r--r--。
• 三个位：属主 / 属组 / 其他人。
• SUID：以"文件属主"身份执行（如 /usr/bin/passwd 普通用户也能改密码写 /etc/shadow）；发现可疑 SUID 是安全检查点（find / -perm -4000）。
• 💡 记：chmod 数字=三段相加；SUID 是"借用老板身份办事"。

L4｜systemd 常用 📌

• systemctl start/stop/restart/status/enable 服务；enable 设开机自启；systemctl list-units --failed 看失败。
• 日志用 journalctl -u 服务名 -f，比看文件方便。
• 写一个 service：放 /etc/systemd/system/xxx.service，含 Unit/Service/Install，ExecStart、Restart=always。
• 改了文件要 systemctl daemon-reload。
• 💡 记：管服务找 systemctl，看日志找 journalctl，改完要 reload。

L5｜cron 定时任务 📌

• crontab -e 编辑；格式：分 时 日 月 周 + 命令（*/5 * * * * = 每 5 分钟）。
• 日志：grep CRON /var/log/cron；环境变量少，命令要写绝对路径。
• 💡 记：五颗星依次"分时日月周"，从大到小排。

L6｜grep / sed / awk 实用三件套 📌

• grep：过滤行 grep -i 关键字 文件、-E 正则、-c 计数、-v 反选。
• sed：流式替换/删除 sed -i 's/旧/新/g' 文件、sed -n '10,20p' 打印指定行。
• awk：按列处理 awk '{print $1, $NF}'、awk -F: '{print $1}' 指定分隔符、求和 awk '{sum+=$1} END{print sum}'。
• 💡 记：grep 找行、sed 改行、awk 拆列。

L7｜磁盘满了 & 删了文件空间不释放 📌

• 排查：df -h 看哪个分区满 → du -sh /xx/* | sort -rh | head 逐层找大文件；df -i 看 inode 是否被小文件占满。
• 删了空间没释放：文件被进程占用（删的是目录项，句柄还开着）→ lsof | grep deleted 找到进程重启或 > 文件 清空。
• 💡 记：满了先 df 再 du；删不干净找 lsof deleted。

L8｜SSH 加固 & 免密登录 📌

• 免密：ssh-keygen 生成密钥 → 公钥追加到目标机 ~/.ssh/authorized_keys（或 ssh-copy-id）→ 私钥留本地。
• 加固：禁 root 密码登录（PermitRootLogin no）、禁密码登录（PasswordAuthentication no）、改端口、只放必要端口、Fail2ban。
• 💡 记：公钥上锁、私钥开门，锁装到对方门上。

L9｜查看日志的正确姿势

• 实时跟踪：tail -f 日志；查关键字 grep -n 关键字。
• systemd 服务：journalctl -u 服务 -f --since "10 min ago"。
• 容器：kubectl logs -f pod -c 容器、docker logs 容器。
• 排障顺序：先看有没有报错关键字 → 按时间倒序看上下文 → 结合监控看是突发还是持续。

---

模块四 ｜ Docker 容器

D1｜镜像 vs 容器 📌

• 镜像：只读模板（代码+环境+依赖），相当于"安装包/类"。
• 容器：镜像运行后的实例，有可写层，相当于"跑起来的进程/对象"。
• 💡 记：镜像是菜谱，容器是照着做的菜。

D2｜镜像分层原理 📌

• Dockerfile 每条指令生成一层（只读层），容器启动时在最上面加一层可写层。
• 好处：① 层可复用------本地已有基础层就只拉新层，pull 快、省磁盘；② 多个镜像共享底层。
• 写文件用"写时复制"：改文件先复制到可写层再改，不改底层。
• 💡 记：分层=搭积木，公共底座只搬一次。

D3｜容器隔离用什么实现的 📌

• Namespace：隔离"视图"------PID/网络/文件系统/用户/UTS/IPC，容器里只能看到自己那套。
• Cgroup：限制"资源"------CPU、内存、磁盘 IO 配额。
• 底层共用宿主机内核，所以容器里不能随便换内核（这就是 Docker vs VM 的本质差异）。
• 💡 记：Namespace 管"看得见什么"，Cgroup 管"能用多少"。

D4｜Docker vs 虚拟机 📌

• Docker：共享宿主机内核，秒级启动，资源开销小，隔离弱（内核级）。
• VM：每个有独立内核（Hypervisor 虚拟硬件），隔离强，启动分钟级，资源开销大。
• 💡 记：容器是"同住一栋楼分房间"，VM 是"各自盖独栋"。

D5｜Docker 网络模式 📌

• bridge（默认）：容器通过虚拟网桥（docker0）互通，对外靠端口映射 -p。
• host：直接用宿主机网络，无隔离、性能好（不适合多容器同端口）。
• none：无网络。
• container：与指定容器共享网络栈（如 sidecar 用 localhost 互访）。
• 跨主机：overlay 网络（Swarm/K8s 的 CNI 也类似思路）。
• 💡 记：默认 bridge 隔房间，host 住客厅，container 合租一间。

D6｜数据卷：volume vs bind mount 📌

• volume：由 Docker 管理（/var/lib/docker/volumes），推荐，易备份迁移。
• bind mount：直接挂宿主机路径（-v /宿主机:/容器），方便调试，但权限要小心。
• 容器删了数据卷默认还在（除非 -v 一起删）。
• 💡 记：volume 是"托管仓库"，bind 是"直接指到我家柜子"。

D7｜Dockerfile 怎么优化 📌

• ① 多阶段构建：builder 编译 → 最终镜像只拷产物，体积小；② 选小基础镜像（alpine/distroless）；③ 合并 RUN 减少层；④ .dockerignore 排除无关文件；⑤ 把不变的依赖放前面吃缓存；⑥ 非 root 运行、加 HEALTHCHECK。
• 💡 记：小底、少层、多阶段、吃缓存、非 root。

D8｜CI 里要 build 镜像怎么解决 Docker in Docker 📌

• 方案一：跑 docker:dind 服务（容器里起 Docker daemon），隔离好、慢一点。
• 方案二：挂载宿主 docker.sock（DinD），快但有安全风险（等于给了宿主 root）。
• GitLab Runner executor=docker 时 build 镜像常用 dind service。
• 💡 记：要干净用 dind，要快用 sock，但 sock 危险。

D9｜镜像 tag 规范：为什么不用 latest 📌

• 用 commit SHA / 时间戳当 tag：镜像 ↔ 代码版本一一对应，可追溯、可精确回滚。
• latest 是"移动标签"，指向不确定，无法回滚、无法复现，生产禁止。
• 💡 记：latest 是"薛定谔的版本"，commit SHA 才是身份证。

D10｜Docker 常用命令 & 容器排障 📌

• docker ps -a 看状态（Exited 要看退出码）；docker logs 看日志；docker exec -it 进容器。
• docker inspect 看配置/挂载/网络/退出原因（OOMKilled）。
• 退出码：0 正常退出；137 = SIGKILL（多半 OOM）；143 = SIGTERM（被停）。
• 容器删了数据就没了 → 用 volume；进程是 1 号进程，信号要能正确处理（优雅退出）。
• 💡 记：状态用 ps、原因用 inspect、日志用 logs、进去用 exec。

---

模块五 ｜ Kubernetes

K1｜架构 & 各组件职责 📌

• 控制面（Master）：etcd（集群状态数据库，大脑）、kube-apiserver（唯一入口，所有操作过它）、kube-scheduler（给 Pod 选节点）、kube-controller-manager（各种控制器调谐）。
• 数据面（Node）：kubelet（管本机 Pod/容器，报状态）、kube-proxy（维护 Service 转发规则 iptables/ipvs）、容器运行时（containerd）。
• 💡 记：etcd 记账、apiserver 收银台、scheduler 分座位、kubelet 干活上报、kube-proxy 指路。

K2｜为什么最小调度单位是 Pod，不是容器 📌

• Pod 是一组"紧密耦合的容器"：共享网络栈（同 IP/端口）、共享存储卷、同节点同生命周期。
• 典型：主容器 + sidecar（日志采集、代理）；适合"必须在一台机器、通过 localhost 互访"的场景。
• 💡 记：Pod 是"一个屋檐下的一家人"，容器是家人。

K3｜常用控制器对比 📌

• Deployment：无状态应用，滚动更新/回滚，最常用。
• StatefulSet：有状态（数据库），稳定网络标识 + 稳定存储（PV），顺序启停。
• DaemonSet：每个节点跑一个（日志采集 Filebeat、监控 node-exporter）。
• Job：跑一次任务；CronJob：定时任务。
• 💡 记：无状态 Deployment、有状态 StatefulSet、每节点 DaemonSet、一次性 Job。

K4｜Service 类型 & kube-proxy 📌

• ClusterIP：集群内虚拟 IP（默认），外部访问不到。
• NodePort：每节点开一个端口，外部可访问。
• LoadBalancer：云厂商 LB 指向 NodePort。
• Headless Service：不给虚拟 IP，直接返回 Pod IP 列表（StatefulSet 用）。
• 原理：kube-proxy 用 iptables/ipvs 把 Service IP 转发到后端 Pod；Endpoints 记录"谁是可用的 Pod"。
• 💡 记：ClusterIP 内部用、NodePort 开端口、LoadBalancer 上云、Headless 直连 Pod。

K5｜Service vs Ingress 📌

• Service：四层（L4），解决"服务发现 + 集群内负载均衡"。
• Ingress：七层（L7），按域名/URL 路由到不同 Service，还能配 HTTPS、限流（nginx-ingress 实现）。
• 访问链路：域名 → DNS → Ingress（按 Host 路由）→ Service（ClusterIP）→ Endpoints → Pod。
• 💡 记：Service 是"楼内分机号"，Ingress 是"前台总机按分机转"。

K6｜ConfigMap / Secret 📌

• ConfigMap：存非敏感配置（明文），挂载成文件或环境变量。
• Secret：存敏感信息（密码、证书），etcd 里 base64 存储（默认不加密，生产开 etcd 加密）。
• 改了 ConfigMap/Secret：已挂载为文件会热更新（env 不会），Deployment 通常要 rollout restart。
• 💡 记：明文用 ConfigMap，敏感用 Secret，别把密码写镜像里。

K7｜PV / PVC / StorageClass 📌

• PV：管理员提供的存储资源（NFS/云盘/local），独立于 Pod。
• PVC：应用"申请"存储的凭证，绑定到匹配的 PV。
• StorageClass：动态供给------PVC 没有现成 PV 时按 StorageClass 自动创建（如云盘）。
• 💡 记：PV 是仓库里的货，PVC 是提货单，StorageClass 是"按单自动补货"。

K8｜调度流程 & 亲和性 / 污点 📌

• 流程：Pod 创建 → scheduler 过滤（资源够不够、污点容忍）→ 打分（亲和性、资源均衡）→ 选最优节点 → kubelet 拉镜像起容器。
• 污点 Taint：给节点打标记（如专用 GPU 节点），Pod 有对应 Toleration 才能调度上去。
• 亲和性：nodeSelector（指定节点标签）、nodeAffinity（优先/必须）、podAffinity（和某类 Pod 靠近/远离）。
• 💡 记：scheduler 先"筛"再"评"；污点是"门禁"，容忍是"通行证"。

K9｜探针三兄弟 📌（✅ 详细版见主文档）

• startupProbe：启动慢的应用先用它，成功前不跑另外两个，防止启动慢被误杀。
• readinessProbe：就绪探针，失败只摘流量（Endpoints 移除），不重启；适合查外部依赖（DB 通不通）。
• livenessProbe：存活探针，失败就杀容器重启；别把 DB 连通性放这里（重启治不好 DB，会放大故障）。
• 💡 记：startup 管"起来没"，readiness 管"能不能接客"，liveness 管"还活着没"。

K10｜滚动更新 & 回滚 📌（✅ 详细版见主文档）

• 更新：kubectl set image deploy/xx 容器=镜像:tag 或 kubectl edit/apply，触发滚动。
• maxSurge（默认 25%）：最多允许多起几个新 Pod；maxUnavailable（默认 25%）：最多允许多少旧 Pod 同时不可用。
• 新 Pod 起不来/探针不过 → 更新卡住，旧 Pod 继续服务，不中断；CI 里用 kubectl rollout status 判断成败。
• 回滚：kubectl rollout undo deploy/xx（回到上一个 revision）；镜像还在仓库，tag 可追溯。
• 💡 记：先增后减不中断，起不来就停住等人工，出问题 rollout undo。

K11｜etcd 是什么 & 为什么要备份 📌

• etcd：集群唯一状态源（所有资源、配置、证书都存在它里面），一致性靠 Raft。
• Master 挂了影响调度/控制面；etcd 数据坏了集群就"失忆"。
• 生产：奇数节点（3/5）保证多数可用 + 定期快照备份（etcdctl snapshot save）异地保存。
• 💡 记：etcd 是集群的"大脑记忆"，丢了就失忆，必须奇数 + 备份。

K12｜资源 requests / limits & HPA 📌

• requests：申请量（调度依据，保证下限）。
• limits：上限（超过会 CPU 限流 / 内存被杀 OOMKilled，退出码 137）。
• QoS：requests=limits 是 Guaranteed（最稳）；只设 requests 是 Burstable；都不设是 BestEffort（先被杀）。
• HPA：按 CPU/自定义指标自动扩缩副本数（kubectl get hpa）。
• 💡 记：requests 是"保底工资"，limits 是"预算上限"，内存超限直接 OOM。

K13｜集群证书过期怎么办 📌

• 先看：kubeadm certs check-expiration 看剩余时间。
• 处理：kubeadm certs renew all 续期 → 重启相关组件/更新 kubeconfig → 各节点 kubelet 证书同步。
• 预防：证书有效期监控（1 年），提前续期，别等过期集群瘫痪再救。
• 💡 记：证书会过期是常态，提前续 + 监控剩余天数。

K14｜Pod 生命周期 / 重启策略 / 终止流程

• 状态：Pending（等调度/拉镜像）→ Running → Succeeded/Failed；还有 CrashLoopBackOff（反复崩溃退避）。
• restartPolicy：Always（默认，Deployment）/OnFailure/Never。
• 终止：发 SIGTERM → 等优雅退出（terminationGracePeriodSeconds，默认 30s）→ 超时才 SIGKILL；所以应用要会处理 SIGTERM 做优雅下线（摘流量、存状态）。
• 💡 记：先礼后兵------先 SIGTERM 请它体面走，超时才 SIGKILL。

---

模块六 ｜ MySQL 速背版（详细问答见《秋招模拟面试-问答整理》M1--M17）

M1｜事务 ACID & 隔离级别 📌（✅）

• ACID：原子性（undo log 回滚）、一致性（账要平）、隔离性（锁+MVCC）、持久性（redo log）。
• 隔离级别从松到严：读未提交 → 读已提交 → 可重复读（MySQL 默认）→ 串行化。
• 三个问题：脏读（读未提交数据）、不可重复读（同一条两次读不一样）、幻读（范围查询行数变了）。可重复读下 InnoDB 靠 MVCC+间隙锁基本防住幻读。
• 💡 记：脏读只有"读未提交"有；MySQL 默认可重复读。

M2｜MVCC 一句话 📌（✅）

• 每行通过 undo log 保留多个版本，读走"快照"（事务开始那一刻），读写互不阻塞 → 高并发。
• 💡 记：读旧版本快照，不挡别人写。

M3｜为什么索引用 B+ 树 📌（✅，桌面有配图）

• 内部节点只存 key → 一页塞上千个 key → 树矮（3~4 层）→ IO 少；数据全在叶子且有序 + 叶子链表 → 范围查询顺着扫。
• 对比：哈希只能等值查询、不能范围/排序；普通二叉树树太高。
• 💡 记：又矮、又稳、又能范围扫。

M4｜聚簇索引 / 回表 / 覆盖索引 📌（✅）

• 聚簇索引（主键）：叶子直接存整行，找到 key 就是行。
• 二级索引：叶子存"索引列+主键"，查不到整行要拿主键再查一次 = 回表。
• 覆盖索引：要查的列都在索引里，不用回表（select 只查索引列）。
• 💡 记：二级索引先找主键再回表；覆盖索引"索引里啥都有"。

M5｜索引失效场景 📌（✅）

• ① 违反最左前缀；② 对索引列用函数/运算；③ 隐式类型转换；④ like '%xx'（前导通配）；⑤ 用 or 且一边没索引；⑥ 优化器判断全表更快（数据量小）。
• 💡 记：最左、别碰函数、别隐式转换、前导 % 必失效。

M6｜redo log / undo log / binlog 📌（✅）

• redo log：崩溃恢复，保证持久性（WAL：先写日志再刷盘）。
• undo log：回滚 + MVCC 版本链。
• binlog：逻辑日志，主从复制 + 数据恢复；和 redo 的区别：redo 是 InnoDB 物理日志，binlog 是 Server 层逻辑日志。
• 💡 记：redo 防断电丢、undo 能反悔、binlog 给"分身"（从库）看。

M7｜主从复制原理 & 延迟怎么处理 📌（✅）

• 原理：主库写 binlog → 从库 IO 线程拉取写 relay log → 从库 SQL 线程回放。
• 延迟原因：从库单线程回放慢、大事务、主库写压力大。
• 缓解：并行复制、拆大事务、读写分离把读压力分流、从库硬件跟上。
• 💡 记：主写 binlog、从拉 relay、SQL 线程回放；延迟=回放跟不上。

M8｜慢 SQL 怎么排查 📌（✅）

• 开慢日志（long_query_time）→ 拿到慢 SQL → EXPLAIN 看 type（要 range/ref/const，别 ALL 全表）、key（有没有走索引）、rows（扫了多少行）。
• 常见修复：加/改索引、避免 select *、避免索引失效写法、必要时改写 SQL。
• 💡 记：先慢日志抓 SQL，再 EXPLAIN 看有没有走索引。

M9｜锁：行锁 / 间隙锁 / 死锁 📌

• 行锁：锁具体记录；间隙锁：锁一个范围（防幻读）；next-key = 行锁+间隙锁。
• 死锁：两个事务互相等对方锁 → InnoDB 检测后回滚代价小的事务；应用侧：固定加锁顺序、缩短事务。
• 💡 记：行锁锁记录、间隙锁锁范围、死锁回滚小的。

---

模块七 ｜ 中间件与工具

R1｜Redis 是什么 & 为什么快 📌

• 内存数据库（键值），单线程执行命令 + IO 多路复用（epoll）→ 无锁竞争、避免上下文切换；纯内存操作本身快。
• 常用于：缓存、分布式锁、计数器、排行榜、Session 共享。
• 💡 记：快在"内存 + 单线程 + 多路复用"。

R2｜Redis 数据结构 & 场景 📌

• String（缓存/计数器）、Hash（对象）、List（消息队列/最新列表）、Set（去重/抽奖/共同好友）、ZSet（排行榜，带分数排序）。
• 💡 记：榜单一律 ZSet，去重用 Set，消息用 List。

R3｜Redis 持久化 RDB / AOF 📌

• RDB：定期快照，文件小、恢复快，但可能丢最后一次快照后的数据。
• AOF：追加写命令，丢得少（可配 everysec），文件大，恢复慢；可开 AOF 重写压缩。
• 生产常两者结合。
• 💡 记：RDB 拍照片、AOF 记流水账；照片会丢最近的，流水账完整但长。

R4｜缓存穿透 / 击穿 / 雪崩 📌

• 穿透：查不存在的数据，绕过缓存打 DB → 布隆过滤器 / 缓存空值。
• 击穿：某个热点 key 过期瞬间大量请求打 DB → 互斥锁 / 逻辑过期 / 永不过期。
• 雪崩：大量 key 同时过期或 Redis 挂了 → 过期时间加随机值 / 集群高可用 / 限流降级。
• 💡 记：穿透=查了个寂寞，击穿=一个 key 倒下，雪崩=一片 key 同时倒下。

R5｜Redis 过期删除 & 内存淘汰

• 删除策略：惰性删除（取时发现过期才删）+ 定期抽样删除。
• 内存淘汰：内存满时按策略踢，常用 allkeys-lru（LRU 踢最久没用）、volatile-ttl 等。
• 💡 记：平时懒删+定时抽，满了按 LRU 踢。

NG1｜Nginx 反向代理 / 负载均衡 / location 优先级 📌

• 反向代理：proxy_pass http://后端;；负载均衡 upstream 配 server 列表 + 策略（轮询/权重 ip_hash）。
• location 匹配优先级：精确 = → 前缀 ^~ → 正则 ~ → 普通前缀（最长匹配）。
• 用途：静态资源、反向代理、HTTPS 卸载、限流、日志。
• 💡 记：= 最优先，^~ 其次，正则再次，普通前缀兜底。

A1｜Ansible 优势 & 幂等性 📌

• 无 agent（走 SSH）、声明式（描述"最终状态"，不管过程）、模块化、幂等。
• 幂等：重复执行结果一致，不会重复改/重复装；写 playbook 要保证操作可重跑。
• 对比 Shell：Shell 是过程式、每次从头执行，容易"跑一次没问题、跑两次出问题"。
• 💡 记：Ansible 说"我要什么"，Shell 说"给我一步步做"。

G1｜Git 回滚：reset vs revert 📌

• reset：把分支指针往回退（会改历史，本地用；已推送要小心，需强推）。
• revert：新提交"反向撤销"某次提交（不改历史，远程协作安全）。
• 日常：改错没推用 reset 爽快；线上已推送用 revert 稳。
• 💡 记：reset 倒带重来，revert 打个补丁否认。

SH1｜Shell 高频小点 📌

• $? 上一条命令退出码（0 成功）；set -e 出错即停。
• 变量：a=1（赋值无空格）；$(cmd) 取命令结果；双引号会展开变量，单引号原样。
• 判断：if [ -f 文件 ]; then；[ -z "$x" ] 判空。
• 后台：cmd & + wait；重定向 > 日志 2>&1。
• 💡 记：退出码问 ?，取结果用 ( )，判空 -z，后台 & + wait。

---

模块八 ｜ 场景题精选（考排障思路，无标准答案）

SC1｜Pod 一直 CrashLoopBackOff 怎么查 📌（✅）

• 排查五步：
  • ① kubectl get pod 看状态和重启次数；
  • ② kubectl describe pod 看 Events（ImagePullBackOff？OOMKilled？探针失败？）；
  • ③ kubectl logs / logs -p 看当前和上次崩溃日志；
  • ④ 查配置：ConfigMap/Secret 挂没挂对、资源 limit 是否太小、镜像 tag / 启动命令是否存在；
  • ⑤ 修复后观察是否恢复。
• 顺序：现象 → Events → 日志 → 配置资源，别瞎猜。
• 顺序：现象 → Events → 日志 → 配置资源，别瞎猜。

SC2｜502 / 503 / 504 分别怎么排 📌

• 502 Bad Gateway：网关连不上/上游返回无效 → 查后端服务起没起、端口对不对、Pod 是否 CrashLoop、nginx upstream 配置。
• 503：服务暂时不可用（过载/无可用后端）→ 看是否限流、后端全部摘除、容量不足。
• 504：网关等上游超时 → 查后端慢请求、DB 慢查、超时时间配太短。
• 套路：从前到后逐层 curl（LB → nginx → Service → Pod），每层看时延和状态码。

SC3｜Service 访问不通怎么排 📌（✅）

• 排查四步：
  • ① kubectl get endpoints 看有没有后端；没有 → 查 Pod 标签和 Service selector 是否匹配；
  • ② kubectl get pod -o wide 拿 Pod IP，分别 curl Pod IP 和 Service IP：Pod 通、Service 不通 → 问题在 kube-proxy / iptables-ipvs 规则；
  • ③ 都不通 → 进容器 nslookup 查 DNS / 网络插件；
  • ④ 跨节点不通 → 查 CNI（Calico）。
• 套路：先看 endpoints，再比对 Pod IP vs Service IP，分层缩小范围。
• 套路：先看 endpoints，再比对 Pod IP vs Service IP，分层缩小范围。

SC4｜CPU 100% / 负载高怎么排 📌

• ① top 按 P 找 CPU 高的进程 → ② top -Hp PID 定位线程 → ③ 看是不是 GC/死循环/慢查询 → 应用栈（jstack/perf）；④ 看监控是持续高还是波动；⑤ 结合最近发布/流量判断是不是新版本引入。
• 💡 记：进程 → 线程 → 代码/日志，一层层钻。

SC5｜磁盘满了怎么处理（线上版）📌

• ① df -h 确认哪个分区；② du -sh /xx/* 找大文件（日志/镜像/临时文件）；③ 日志清理：轮转（logrotate）、清大日志、删旧备份；④ 容器/镜像占空间 docker system df、docker system prune；⑤ 删了不释放查 lsof | grep deleted。
• 根因治理：日志要轮转、监控磁盘使用率提前告警，别等写满。

SC6｜发布新版本后出问题：回滚还是继续查 📌

• 原则：先恢复再定位 。有明显回归（报错率升、核心功能挂）→ 先 kubectl rollout undo 回滚止血，再慢慢查根因。
• 影响面小、能快速定位 → 可继续查，但设好止损线（如 5 分钟内没定位就回滚）。
• 复盘：这次为什么没被发现（灰度？监控？测试覆盖？），沉淀改进。

SC7｜半夜告警风暴 / 大面积故障怎么应对 📌

• ① 先判断影响面：是不是核心服务、是不是大面积；② 优先恢复服务：重启/回滚/扩容/切流，而不是马上查根因；③ 同步：群里说清现状和动作，别一个人闷头查；④ 恢复后再定位根因 + 写复盘（时间线、根因、改进项）。
• 💡 记：止血 → 同步 → 定位 → 复盘。

---

📌 考前 30 分钟快刷清单

• N1 握手挥手、N3 HTTPS、N5 TCP 可靠、N8 代理：闭眼能画
• O1/O4/O7：进程线程协程、死锁四条件、OOM 排查
• L1 排查命令、L7 磁盘满：能脱口而出
• D2 分层、D3 隔离、D7 Dockerfile 优化：讲得清
• K1 组件、K4 Service、K9 探针、K10 滚动更新回滚：重点中的重点
• M1/M3/M4/M6：MySQL 必背底线
• R1--R5：Redis 五连问
• SC1--SC7：每个都能按"先现象→再分层→先恢复再定位"讲
• 简历数字都有故事：2 分钟上线、3 秒自愈、RHCE/RHCSA

---