面经策

系统每天晚上都会有一小时左右的时间瘫痪，你觉得可能的原因是什么？有遇到过这样的情况吗？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

"每天晚上固定时段瘫痪、持续约一小时后自愈"——规律性是最大的线索：这不是随机故障，而是某个定时任务在固定时间点把资源打满。自愈说明资源后来被释放了。

最可能的原因（按概率排序）

  1. 定时批处理任务：对账、报表、全量同步、离线计算直接跑在业务库/应用服务器上，时间恰好撞上晚间业务小高峰（不少业务晚 8-11 点才是峰值，海外业务更是如此）。
  2. 数据库备份：xtrabackup/mysqldump 在业务库上执行，IO 打满导致所有 SQL 变慢，连锁拖垮连接池和线程池。
  3. 日志/归档/统计脚本：大表 DELETE 清理、老数据归档引发锁和 IO 争用。
  4. 缓存集中过期或定时刷新：大量 key 同时失效，请求穿透打到 DB。
  5. 上游合作方的定时拉数：第三方每天定时来全量拉接口，没做限流。

排查动作

  • 把监控曲线（CPU/IO/DB 连接数/慢 SQL）和 crontab、调度平台任务清单对时间轴，基本一眼定位。
  • 确认任务跑在哪：和应用同机？和业务库同实例？这两点是中小公司最常见的设计欠账。

解决思路（业务架构视角）

  • 错峰：任务挪到真正的业务低峰（凌晨 2-5 点），多个任务本身也要拉开间隔，避免"任务自己叠高峰"。
  • 剥离：批处理迁到从库或大数据平台（binlog 同步后离线算），报表类需求绝不允许直连交易库。
  • 限流：全量拉数的接口加速率和配额。
  • 根本上这是成本问题：很多团队任务和交易混部是省机器，但一晚瘫痪一小时的业务损失（转化、客诉）远超多加一台从库的钱。用"每小时故障的业务折价"去申请资源，比讲技术原理更容易推动。

🏗 系统架构师 ​

"每晚固定一小时瘫痪"是强时间特征，我第一反应一定是定时任务集中执行，这属于方法论里的"故障时间与调度日历对齐法"。

最可能的原因（按我实际遇到的概率排序）

  • 批处理任务集中：晚上跑对账、结算、报表、标签计算，几十条大 SQL 同时打在主库上，IO 打满、连接池被占光，在线请求排队超时。
  • 备份窗口：xtrabackup/mysqldump 全量备份 + 传输，磁盘 IO 和网络双吃满。
  • 缓存集中失效/重建：白天写入的 key 设了固定 TTL，或夜里跑缓存预热任务导致大量 key 同时过期，请求穿透到 DB。
  • 日志切割/归档：日志压缩传输、HDFS 归档任务占满磁盘带宽。
  • 下游依赖的批量窗口：比如风控、渠道的日切任务，把你们的调用拖慢。

排查动作 把监控的故障时间轴和调度平台（crontab/xxl-job）的任务清单做时间对齐，基本一眼锁定；再看那一段的慢 SQL 日志、DB 的 IO util、连接池 active 曲线验证。

治理方案（治本）

  • 任务编排平台统一管理所有批任务：错峰调度、设置 DB 侧并发上限和限速（比如同时最多 2 个重 SQL）。
  • 批处理走独立的从库/数仓，物理隔离在线与离线负载——这是我首选的架构级解法。
  • 备份改增量 + 物理快照，避开业务窗口。
  • 缓存 TTL 加随机抖动，预热任务限速。
  • 兜底：在线链路对 DB 加连接池隔离 + 熔断，即使批任务失控也不至于全线瘫痪。

💻 全栈开发专家 ​

每晚固定时段瘫痪一左右，第一反应就是定时任务——规律性故障先查 crontab 和调度平台。

我的排查顺序

  1. 对时间点：监控上确认瘫痪起止时间和哪个任务 Schedule 重合。看 XXL-JOB/公司调度平台该时间窗口跑了什么。
  2. 看故障时系统指标：CPU、IO wait、DB 连接数、慢查询数。三种典型画像：
    • IO wait 飙高 + 大量慢查询 → 批处理任务全表扫，把 buffer pool 和磁盘打爆。
    • CPU 满 → 定时报表聚合、大批量计算。
    • DB 连接池耗尽 → 定时任务并发开太多连接，业务拿不到连接。

我实际遇到过的案例

  • 凌晨 2 点数据组直接 SELECT * 全量抽取业务大表，没有走从库，主库磁盘 IO 打满，接口集体超时。解决：抽取强制走从库 + 限速（DataX 限流），主库账号回收。
  • 备份任务（mysqldump）和业务高峰重叠。解决：挪到低峰 + 用 XtraBackup 物理备份。
  • Elasticsearch 定时 force merge / 大索引重建占满节点 CPU。
  • 定时把 Redis 热 key 全量刷过期，请求穿透到 DB。
  • 老代码里 @Scheduled 没配线程池，任务堆积后所有任务挤一个线程，执行时间越拖越长。

长期机制

  • 所有定时任务集中托管（XXL-JOB），任务级的资源隔离（跑在独立实例/容器，或 DB 层面用不同账号限流）。
  • 任务执行时间偏移打散（避免整点扎堆）。
  • 值班告警里加上「定时任务开始/结束」事件，故障时一眼关联。

这种题面试官想听的就是：用时间规律锁定定时任务 → 指标定位资源瓶颈 → 隔离/限速治理的完整思路。