概述

线上一套微服务里的移动端查询接口突然”忽快忽慢”：快的时候几十毫秒返回，慢的时候要等上秒级，而且同一个接口、同样的参数，前后两次请求表现完全不同。服务是双副本部署，监控大盘上宿主机 CPU 长期 90% 以上空闲——看起来谁都不缺资源。

• 故障现象：同一查询接口延迟呈双峰分布（几十 ms / 秒级），双副本中一个 pod load 6+、三十个线程处于运行态，另一个 pod load 0.5、全部休眠；
• 根因：Pod 的 CPU limit 只有 0.4 核（cpu.cfs_quota_us=40000/100000），繁忙副本在 38.8% 的调度周期里打穿 CFS 配额被整体冻结，所有业务线程以 100ms 为台阶周期性停摆；
• 关键反直觉点：该 pod 平均 CPU 用量只占配额的 25%，”平均很闲”与”高频被限流”并不矛盾——限流看的是峰值，不是均值。

调大 limit 后 nr_throttled 归零、接口延迟恢复平稳。这篇复盘记录完整排查路径，以及两个值得单独记录的坑：top 的 TIME+ 单位误读（差 60 倍），和容器里没有 jcmd/jstat 时的取证替代。文末后记补充同日把排查铺向全集群后的发现：这不是一个服务的病，是整个集群的系统性配额问题。

阅读全文

生产系统里最不起眼、又最容易在并发下翻车的代码，大概就是「查最大单号然后加一」这种两行取号。上周就撞上了一次：两位仓管员前后差 2 秒各做了一笔外部调拨，落库后两张调拨单单号相同，第二笔回写 ERP 时被对方系统以「编码唯一性要求：该编码已被使用」拒收。

排查根因、评估方案、换成 Redis 原子发号、真机并发压测验证，一路走下来，恰好把 Redis 的一大串面试高频考点串成了线。这篇文章先复盘事故与修复，再把考点一次讲透。

阅读全文

概述

一套跑在 K8s 上的 MES 系统里，辅助服务 Pod mes-app-assist 频繁重启：kubectl describe pod 显示容器因 Liveness 存活探针连续失败，被 kubelet 强行终止（退出码 137 / SIGKILL）。

• 故障现象：Pod 反复重启，退出码 137 初看像 OOMKilled，但事件日志明确写着 Liveness probe failed；
• 根因：外部接入层 Nginx 所在宿主机的文件描述符上限（nofile）过低——worker 进程软限制仅 1024。并发连接持续累积后，Nginx 报 24: Too many open files，既无法建立到后端 NodePort 的 socket 连接，连返回错误页 50x.html 的文件句柄都拿不到，经它转发的请求只能以 HTTP 500 或超时收场；
• 误杀机制：该 Pod 的 Liveness 探针被配置成跨节点探测外部 Nginx 反代地址——外部网关句柄耗尽，被 kubelet 误判为容器死亡，实际健康的后端容器被误杀重启。外部故障沿着探针链路反向传导进了 K8s 内部。

阅读全文

有东西被加密了, 请输入密码查看.

阅读全文

有东西被加密了, 请输入密码查看.

阅读全文

数据库备份这件事有个残酷的悖论：平时它毫无产出，关键时刻它是唯一救命的——所以它的质量不能靠”平时看起来在跑”来保证，只能靠恢复演练来证明。本篇拆一套真实在跑的 MySQL 物理备份一键化方案：CentOS 7 离线环境、XtraBackup 加压缩、七天全量加每日增量链、保留九十天，外加一个恢复演练脚本和一段”增量链四连自愈”的修复实录。

这个方案的脚本量不大（一个安装入口、一个备份脚本、一个恢复脚本），但注释里沉淀的四次修复记录，几乎覆盖了增量备份运维的全部经典坑。上一篇运维篇·上讲集群与监控，本篇讲数据的最后防线。

阅读全文

系列二十五篇本已完结，但运维线一直是个缺口——前面讲过的”K8s 部署痕迹”（云主线的 pod 配置、物联篇的 0 号节点）都只是切片。这两篇增补把切片拼成整图：本篇讲一套生产 K8s 部署清单——CentOS 7 自建集群上跑全套 MES 微服务，外加完全自建的 Prometheus 告警监控栈；下一篇讲 MySQL 的物理备份一键化与恢复演练。

先修正一个容易望文生义的误解：这个项目叫 install-k8s，但里面没有一行安装脚本——它是部署清单（manifests）仓库，K8s 集群本身装好后，”把 MES 搬上去”的全部知识都沉淀在这三十八个 YAML 里。这个定位本身就值得说：集群是易耗品，清单才是资产——装集群一天的活，调清单调了一年。

阅读全文

系列最后一篇。前二十六篇是弹药库，这一篇是出膛前的最后一道组装工序：一张二十七问的高频清单（每问标注答案锚点）、三棵追问树（展示面试官怎么从一个问题追到第五层）、几条应答的元规则、以及最容易被浪费的面试最后五分钟——反问环节。

盘点篇给了按提问路径组织的索引，话术篇给了开场与应答的骨架；本篇补的是实战的最后一层——**追问的纵深预演**。面试的分水岭不在第一问答得多好，在第三层追问答不答得住；而第三层的问题是可以预先推演的。

阅读全文

“介绍下你的项目”——这道题答不好，通常不是没做过，是没组织过。做过的东西在脑子里是网状的（盘点篇的索引就是那张网），而面试开口只有线性的几十秒；不预先组织，开口就是”我们用了 Spring Cloud，然后有个工单模块，然后……”——信息全是碎片，面试官听不出形状。

本篇把全系列压缩成嘴上的功夫：30 秒电梯版（两套，按岗位换）、3 分钟结构化版（逐段给话术和每段的目的）、单项目深挖版（面试官说”挑一个讲深点”时的备选）、五个高频追问的应答骨架。所有话术都从前面各篇的真实素材压缩而来——话术不能编，编出来的经不起追问；话术只是把做过的事排成讲得出来的顺序。

阅读全文

系列写到这里，机制、交付、端侧、工具链与运维已经二十四篇，本篇是检索层：把散在二十四篇里的考点按”面试官的提问路径”重排成索引，补上一直欠着的导出与归档拼图，最后画出”一个底座、多种交付、多端工具链”的项目经历地图。面试备战材料写完不难，难的是面试前 30 分钟能不能翻到要复习的那一段——本篇就是为那 30 分钟设计的。

阅读全文