一、事故背景与现象
时间范围
- 2022年2月3日 18:11~18:43(历时32分钟)
受影响系统
系统名称 | 角色 | 影响范围 |
---|---|---|
dc3 | 订单数据库主库 | 订单生成、事务回滚 |
dc4 | 订单数据库从库 | 数据同步、容灾切换 |
业务影响
- 核心业务:手机点餐、C扫B支付订单无法推送至POS系统,购物车初始化失败
- 用户指标:下单成功率下跌至85%(基线99.9%)
- 技术指标:
-
数据库主库CPU峰值98%,连接池耗尽
-
swan_saga_local_branch_transaction
表插入RT飙升至1.8s -
数据库主库因慢查询触发级联雪崩,sjstrmsodc4主库发生ORC切换失败,连接池耗尽。
-
订单号生成服务与事务回滚逻辑共用集群,故障扩散至上游服务(odc.orderprocess、odc.menu等)。
-
其他服务访问sjstrmsodc4开始出现获取连接超时
-
二、处理流程与关键操作
时间线
时间节点 | 关键操作 | 数据指标/效果 |
---|---|---|
18:11 | 上游服务触发超时告警 | 接口超时率75%(持续15分钟) |
18:12 | DBA定位慢SQL(SQL ID:2171f2ab) | 慢查询数1200+/分钟 |
18:15 | 启动跨团队协作(DBA/SRE/Swan) | 参与团队:DBA 3人、SRE 2人、研发4人 |
18:23 | dc4主库ORC切换失败 | 主从延迟峰值90秒 |
18:27 | 分阶段限流(50%→10%→0%) | QPS从5000降至200 |
18:29 | PT-KILL清理慢查询 | 终止慢查询4500+条,CPU回落至40% |
18:42 | 修复索引(新增idx_xid_branch ) | 查询耗时从1.8s降至5ms |
18:43 | 放开限流,服务恢复 | 推单成功率恢复至99.9% |
核心处置手段
-
限流与熔断
- 动态调整SQL流量,优先保护核心链路
- 使用
pt-kill
终止慢查询,释放连接池资源
-
索引修复
- 修正联合索引顺序为
(xid, branch_id)
,消除全表扫描 - 使用
gh-ost
工具执行在线DDL,主从同步延迟归零
- 修正联合索引顺序为
-
业务补偿
- 人工补推**15%**异常订单(依赖商家手动处理)
三、根因分析
直接原因
分类 | 描述 |
---|---|
索引设计缺陷 | swan_saga_local_branch_transaction 表索引顺序错误(idx_bid_xid ),导致DELETE 语句全表扫描 |
业务逻辑耦合 | 订单生成与事务回滚共享数据库集群,缺乏物理隔离 |
间接原因
分类 | 描述 |
---|---|
巡检机制失效 | 全表扫描检测阈值过高(1000行),未覆盖高频低行数场景 |
预案缺失 | 无数据库故障降级工具,依赖人工补偿(耗时2小时以上) |
四、改进措施与验证
技术优化
-
索引治理
- 建立联合索引顺序审核规则,覆盖**100%**高频操作表
- 重建
swan_saga
系列表索引,查询性能提升90%
-
熔断升级
- 开发多维度限流工具(SQL ID + 服务标签),限流覆盖率提升至95%
架构解耦
措施 | 预期效果 | 进度 |
---|---|---|
订单生成服务独立部署 | 降低跨服务影响80% | 2022Q3落地 |
事务回滚表迁移 | 与核心业务物理隔离 | 已完成 |
监控增强
- 全链路追踪:部署慢SQL实时指纹分析,响应时间>50ms自动告警
- 动态阈值调整:全表扫描阈值降至500行,覆盖高频场景
五、系统性改进模型
改进维度 | 具体措施 | 预期收益 |
---|---|---|
技术债务治理 | 索引顺序强制审核(Code Review) | 减少**70%**索引缺陷引发的故障 |
容量韧性 | 核心集群QPS弹性扩容(基线×200%) | 峰值承载能力提升至1.2万QPS |
组织协同 | DBA-研发-Swan联合巡检机制 | 高风险SQL漏检率下降85% |
故障自愈 | 自动化补偿工具 + 无损降级策略 | MTTR从32分钟缩短至8分钟 |
六、经验总结
技术视角
- 索引即资产:高频表需定期审计索引命中率,纳入发布流程卡点
- 容量兜底:核心服务预设弹性扩缩容策略,避免级联故障
管理视角
- 跨团队协作:建立常态化巡检机制,提前暴露耦合风险
- 预案演练:通过真实场景验证工具有效性(如限流覆盖率)
最终结论:通过索引治理、逻辑解耦与自动化工具建设,系统性降低数据库级联故障风险,保障订单核心链路SLA≥99.99%。