04.混沌工程中数据库调用延迟实验

 

这是一次典型的数据库端延迟（Network Delay + Database Query Delay）混沌实验。与之前讨论的磁盘写满不同，这次故障发生在核心依赖的中间件层，其爆炸半径和影响面往往更广，因此对可观测性的依赖也更高。

一、 场景深度剖析：当 MySQL “慢”下来会发生什么？

执行的命令 blade create mysql delay --time 3000 ... 意味着向 book 数据库的 books 表发送了一个带有 3000 毫秒（3秒）额外延迟的 SQL 查询指令。

在实际的微服务架构中，这一操作会引发连锁反应：

1. 调用端线程阻塞：上游业务服务（如订单服务、用户服务）发起数据库查询后，连接池中的工作线程会被挂起等待。

2. 连接池耗尽与雪崩：如果并发量较大，等待的线程会迅速占满数据库连接池（Connection Pool）和 HTTP 连接池。一旦连接池耗尽，后续的正常请求将无法获取连接，从而导致服务不可用。

3. 级联故障：下游数据库延迟可能导致上游服务响应时间（RT）飙升，进而引发网关超时、熔断（Circuit Breaker）甚至整个集群的雪崩效应。

二、 可观测性闭环：从“SQL 延迟”到“服务降级”

作为可观测性平台负责人，你需要指导混沌测试负责人和分布式核心项目组，建立一套针对上述现象的监控与排查标准。

1. 实验前：埋点预期的“黄金指标”

在注入延迟前，需确认监控系统已覆盖以下关键指标：

• MySQL 层面：Query Response Time（查询响应时间分布）、Threads_connected（当前连接数）、Slow Queries（慢查询计数）。

• 服务层面：接口响应时间 P99（应处于正常基线）、连接池活跃线程数（处于合理水位）。

2. 实验中：捕捉“异常尖峰”

执行 ChaosBlade 命令后，可观测性平台应在 Grafana Dashboard 上观察到明显的变化：

• MySQL 监控：books 表的查询耗时会出现明显的尖峰，部分查询耗时可能达到秒级。

• APM 监控（SkyWalking/Pinpoint）：调用链中涉及 SELECT 该表的 Span 颜色会变红，Duration 显著拉长。

3. 实验后：验证“容错方案”的有效性

场景中的“容错方案”通常包括熔断、降级和限流。排查时需验证这些预案是否按预期工作：

• 熔断验证：观察熔断器仪表盘，确认在数据库持续延迟期间，熔断器是否已从 CLOSED 状态转变为 OPEN 状态，从而切断了对故障数据库的进一步调用。

• 降级验证：检查业务逻辑中是否有返回缓存数据或默认值的降级逻辑被执行。

三、 实战排查指南：当数据库延迟告警触发时

如果分布式核心项目组收到“数据库查询延迟过高”或“服务响应极慢”的告警，可以按照以下路径进行排查：

1. 链路追踪（Tracing）定位“慢接口”

• 动作：登录 SkyWalking 或 Jaeger，按服务名筛选，查看 P99 延迟最高的接口。

• 观察点：点击该接口，查看组成调用链的 Span。找到标记为 MySQL 的 Span，确认其 peer.service 是否为 book 数据库，且 duration 是否异常。

2. 指标监控（Metrics）确认“资源瓶颈”

• 动作：在 Prometheus 中查询该业务服务的数据库连接池指标（如 HikariCP 的 active 线程数）。

• 观察点：如果在告警时间点，活跃线程数突然飙升至最大值，说明连接池已被混沌实验完全占满，服务失去了处理能力。

3. 日志分析（Logging）抓取“报错堆栈”

• 动作：在 Loki 或 ELK 中检索该时段内的 ERROR 或 WARN 日志。

• 观察点：关注是否有 ConnectionTimeout、PoolExhausted 或 Read timed out 等关键字。这些是服务在尝试获取资源失败时留下的直接证据。

4. 混沌实验回溯（Chaos Engineering Context）

• 动作：在 ChaosBlade 的日志或通过 blade status 命令，确认实验 UID 与目标 IP 的绑定关系。

• 观察点：将告警触发时间与该实验的启动时间进行对齐，完成因果闭环。

四、 给你的行动建议

为了提升团队的混沌实验效率，建议推动以下落地动作：

1. 建立“中间件故障”专项排查手册：与之前的“磁盘写满”类似，整理一份专门针对 MySQL、Redis、MQ 故障的排查卡片，明确每个环节该看哪个 Dashboard。

2. 推动熔断指标的监控：很多团队只监控业务指标，忽略了基础设施的健康度。建议强制要求所有核心服务接入数据库连接池和熔断器的监控大盘，这是防御此类混沌故障的最后一道防线。

3. 量化演练效果：每次实验后，记录从 MySQL 延迟发生到服务熔断/恢复的总耗时（MTTR），并以此作为评估系统韧性的核心 KPI。

 

 

图片内容展示了一份关于数据库调用延迟的混沌工程实践文档。以下是详细分析：

1. 场景与容错方案

• 模拟场景：文档设定在高并发请求下，数据库服务器因CPU和内存资源耗尽导致响应极慢，最终引发服务雪崩效应。

• 容错方案：提出在客户端高并发场景下，通过对入口流量进行限制（限流）来解决数据库过载问题。

2. 核心模拟步骤（技术实现）

文档详细列出了使用 ChaosBlade 工具针对 Java 应用进行数据库调用延迟注入的操作流程：

1. 定位目标进程：

   • 通过 ps -aux | grep DBPlus... 命令查找运行 Java 应用的进程 ID（PID），图中查找到的 PID 为 23652。

2. 挂载 Java Agent：

   • 执行 blade prepare jvm --pid 23652。这一步是让 ChaosBlade 能够介入目标 JVM 内部进行故障注入的前提。

3. 注入 MySQL 延迟故障：

   • 执行 blade create mysql delay ... 命令。

   • 关键参数解析：

     • --time 3000：设置 SQL 延迟时间为 3000 毫秒（3秒）。

     • --database book / --port 3306：指定目标数据库实例。

     • --sqltype select books：精确匹配针对 books 表的 SELECT 查询语句。

     • --pid 3536：关联到具体的应用进程。

4. 销毁实验：

   • 实验结束后，使用 blade destroy <UID> 命令清除故障，恢复服务正常状态。

3. 结合可观测性的闭环分析

结合您作为可观测性平台负责人的角色，这份文档是建立“实验-监控-排查”闭环的重要依据：

• 预期监控信号：

  • 数据库侧：在注入故障期间，应观测到 MySQL 的 Threads_connected 增加，以及特定 select books 语句的耗时（Duration）突增至 3 秒以上。

  • 应用侧：应观测到应用连接池（如 HikariCP）活跃线程数打满，以及接口 P99 延迟飙升。

• 验证容错方案：

  • 在施加延迟后，需验证文档中提到的“入口流量限制”是否生效。可以通过观察网关或限流器（如 Sentinel/Breaker）的 metrics 指标，确认是否有请求被拒绝或走降级逻辑，从而防止雪崩。

4. 行动建议

建议您将这份文档作为分布式核心项目组的测试用例之一，并要求团队在执行此类实验时，必须提供以下可观测性证据：

1. 链路追踪图：展示延迟注入前后，调用链拓扑的变化（如 MySQL Span 变红）。

2. 监控大盘截图：展示数据库 QPS/RT 与 JVM 连接池状态的联动变化。

3. 日志快照：抓取因超时而产生的 WARN/ERROR 日志，完成最终的复盘报告。