1. 项目背景业务场景某短视频平台在春节期间策划了一场抢红包活动——预计 500 万用户同时在线——10 分钟内产生 300 万次写入。技术团队提前 2 周做了压力测试——在 500 并发下 QPS 8000一切正常。活动当天——前 3 分钟一切平稳——第 4 分钟——突然 Buffer Pool 脏页比例飙到 95%——InnoDB 启动了激烈刷新——磁盘 IO 瞬间打到 100%——所有读写操作排队——P99 延迟从 50ms 飙到 30 秒——大量用户抢到红包但订单创建失败——投诉如潮。事后复盘发现——压测时使用了均匀分布的测试数据——而真实场景中大量用户同时抢同一个红包——热点行竞争 大量 UPDATE 产生了远超预期的脏页。痛点不做过极端场景的故障演练——就无法预见真实生产环境的爆炸热点行雪崩某一行被 500 个线程同时更新——行锁排队长度 500——每个事务等完前面 499 个才轮到自己。磁盘 IO 抖动云磁盘的 IOPS 突发总量耗尽——IO 延迟从 0.5ms 跳到 50ms——数据库突然像卡住一样。连接数爆炸一个微服务故障产生连接泄漏——5 分钟内 max_connections 被打满。Buffer Pool 污染一个全表扫描的备份任务把热点数据全部挤出了 Buffer Pool——命中率从 99% 掉到 45%。本章通过混沌工程的方法——主动注入热点行、磁盘 IO 延迟、连接泄漏和 BP 污染四类故障——观察 MySQL 的应力反应——并给出限流、降级、拆分和异步化的组合策略。2. 项目设计【场景抢红包事故复盘会——小胖一脸挫败】小胖“大师为什么我们的压测环境和真实环境差这么多明明同样的并发量——压测时稳如泰山——真用户一上来就炸了。”大师“因为你的压测数据分布太均匀了——100 万用户随机操作——没有热点。而真实活动中——80% 的用户在抢同一个红包——所有 UPDATE 打在同一行上——形成热点行——这就是锁竞争地狱。压测需要注入’倾斜分布’——模拟热点行被高频访问。”小白“那除了热点行——还有哪些极端场景需要在压测中覆盖”大师“至少要覆盖六个维度——热点行、磁盘 IO 抖动、连接泄漏、Buffer Pool 污染、大事务雪崩、网络分区。每个维度单独注入了——看 MySQL 会有什么反应——你的监控能不能及时告警——你的降级策略能不能生效。这就是混沌工程——不等到真实故障发生——主动制造故障——验证系统的韧性。”技术映射混沌工程 主动注入故障 → 观测系统行为 → 验证告警生效 → 修复薄弱点。是从能跑到可靠的必经之路。小胖“那混沌工程和普通压测有什么区别不都是给系统加压力吗”大师“压测是让你看看系统在’正常压力’下能跑多快——所有请求都均匀分布、没有异常。混沌工程是在系统已经处于压力下时——突然注入故障——看系统能不能扛住。比如——在压测高峰期突然关掉一个从库——看 Router 能不能自动把流量切走——看应用有没有降级策略。压测回答’能跑多快’混沌工程回答’坏了一个零件还能不能跑’。”小白“那磁盘 IO 抖动在云环境里常见吗我们是云数据库——也会有吗”大师“云磁盘的 IOPS 是有突发性能上限的——平时有积分时 IOPS 很高——积分消耗完就会被限速到基线 IOPS。很多团队在压测时积分是满的——觉得磁盘很快——但生产环境是 7×24 小时运行——积分早消耗完了——实际 IOPS 只有基线水平。这就是为什么需要在压测中注入 IO 抖动——模拟积分耗尽的’真实状态’。”技术映射云磁盘 IOPS 概念——突发性能有积分时vs 基线性能积分耗尽后。生产环境长期运行后通常是基线性能——比压测时的突发性能差很多。3. 项目实战3.1 环境准备# 安装混沌工程工具pipinstallmysql-connector-python# Python 客户端用于故障注入脚本# 确认 sysbench 可用sysbench--version3.2 分步实现步骤一热点行注入——模拟秒杀场景-- 步骤目标创建一条热点行——500 个并发线程争抢更新-- 创建热点商品库存 1000USEecommerce;DROPTABLEIFEXISTShot_product;CREATETABLEhot_product(idINTPRIMARYKEY,stockINTUNSIGNEDNOTNULL,versionINTUNSIGNEDNOTNULLDEFAULT0)ENGINEInnoDB;INSERTINTOhot_productVALUES(1,1000,0);# hot_row_storm.py# 步骤目标模拟 500 并发抢同一行——观察锁等待和 TPS 衰减importmysql.connectorimportthreadingimporttimeimportstatistics config{host:127.0.0.1,port:3306,user:root,password:Root123,database:ecommerce}latencies[]lockthreading.Lock()defworker(worker_id,iterations):connmysql.connector.connect(**config)for_inrange(iterations):try:starttime.perf_counter()curconn.cursor()conn.start_transaction()# 热点行——所有线程都抢同一行cur.execute(UPDATE hot_product SET stock stock - 1, version version 1 WHERE id 1 AND stock 0)affectedcur.rowcount conn.commit()elapsed(time.perf_counter()-start)*1000withlock:latencies.append(elapsed)ifaffected0:pass# 库存扣完cur.close()exceptExceptionase:conn.rollback()conn.close()defrun_test(name,concurrency,req_per_worker):globallatencies latencies[]# 重置库存resetmysql.connector.connect(**config)curreset.cursor()cur.execute(UPDATE hot_product SET stock 1000, version 0 WHERE id 1)reset.commit()cur.close()reset.close()print(f\n{name}:{concurrency}threads )starttime.time()threads[]foriinrange(concurrency):tthreading.Thread(targetworker,args(i,req_per_worker))threads.append(t)t.start()fortinthreads:t.join()elapsedtime.time()-startiflatencies:sorted_latsorted(latencies)p50sorted_lat[len(sorted_lat)//2]p95sorted_lat[int(len(sorted_lat)*0.95)]p99sorted_lat[int(len(sorted_lat)*0.99)]print(f Requests:{len(latencies)}, Throughput:{len(latencies)/elapsed:.0f}req/s)print(f Latency: P50{p50:.1f}ms, P95{p95:.1f}ms, P99{p99:.1f}ms)# 不同并发度对比run_test(Hot Row,4,100)run_test(Hot Row,16,100)run_test(Hot Row,64,100)run_test(Hot Row,128,100)# 预期并发越高 → 吞吐不一定上升 → P99 剧烈恶化锁竞争步骤二磁盘 IO 抖动注入——模拟云磁盘突发性能耗尽# 步骤目标用 fio 在数据盘中制造 IO 压力——观察 MySQL 的响应# 1. 先记录基线 IO 延迟sudoioping-c10/var/lib/mysql/# 2. 在后台制造磁盘 IO 抖动sudofio--nameio_storm\--filename/var/lib/mysql/fio_test\--size2G--rwrandwrite--bs64k--iodepth32\--numjobs4--runtime120--time_based# 3. 同时运行 sysbench 观察 TPS 变化sysbench /usr/share/sysbench/oltp_read_write.lua\--mysql-host127.0.0.1 --mysql-port3306\--mysql-userroot --mysql-passwordRoot123\--mysql-dbsbtest--tables4--table-size50000\--threads16--time120--report-interval10\run21|grep-Etps:|transactions:# 4. 停止 IO 抖动sudopkillfiosudorm/var/lib/mysql/fio_test# 5. 观察 InnoDB IO 相关指标在抖动期间的峰值mysql-uroot-pRoot123-e SELECT NAME, AVG_COUNT FROM information_schema.INNODB_METRICS WHERE NAME LIKE %io% OR NAME LIKE %file% ORDER BY AVG_COUNT DESC LIMIT 10; 步骤三Buffer Pool 污染注入——全表扫描挤出热点-- 步骤目标先建立热数据——然后执行全表扫描——观察命中率暴跌-- 1. 先预热——将热点数据加载到 BPSELECTCOUNT(*)FROMorders_largeWHEREuser_id8888;SELECTCOUNT(*)FROMorders_largeWHEREuser_id8888;-- 第二次命中 BP-- 2. 记录当前 BP 命中率-- (从 SHOW GLOBAL STATUS 计算)-- 3. 执行一个全表扫描的大查询——挤出 BP 中的数据SELECTAVG(amount),STDDEV(amount)FROMorders_large;-- 这个扫描会把大量不常用的数据页加载到 BP——淘汰热点数据-- 4. 再查询热点——应该看到 IO 飙升-- 先清空查询缓存RESET QUERY CACHE;SELECTCOUNT(*)FROMorders_largeWHEREuser_id8888;-- 这一次应该是物理读——因为在第 3 步被挤出了 BP步骤四连接泄漏注入——观察连接耗尽过程# connection_leak_storm.py# 步骤目标模拟连接泄漏——观察连接数增长和拒绝连接的时机importmysql.connectorimporttime config{host:127.0.0.1,port:3306,user:root,password:Root123}conns[]print(fmax_connections limit check...)try:foriinrange(600):connmysql.connector.connect(**config)conns.append(conn)ifi%500:print(f Opened{i1}connections)exceptmysql.connector.Errorase:print(f [EXPECTED]{e})print(fTotal connections held:{len(conns)})print(f[In another terminal] mysql -uroot -e SHOW PROCESSLIST | wc -l)input(Press Enter to release all connections...)forconninconns:conn.close()步骤五限流、降级、拆分、异步化——四管齐下的防护策略# protection_strategies.py# 步骤目标展示四种策略在热点行场景中的应用# 策略 1限流Rate Limiting# 在应用层使用令牌桶——每秒只允许 N 个请求到达数据库importtimeclassTokenBucket:def__init__(self,rate,capacity):self.raterate# tokens per secondself.capacitycapacity self.tokenscapacity self.lasttime.time()defconsume(self):nowtime.time()self.tokensmin(self.capacity,self.tokens(now-self.last)*self.rate)self.lastnowifself.tokens1:self.tokens-1returnTruereturnFalse# 使用在调用数据库前——先申请 token# if not token_bucket.consume():# return Too many requests, please retry later# 策略 2降级Degradation# 如果数据库 RT 1 秒——返回缓存中的库存数量可能不是实时的——但至少不超时# if db_rt 1000:# return redis.get(stock:hot_product)# 策略 3拆分热点行第 20 章# 将热点行拆分为 10 个子行——并发度提升 10 倍# 策略 4异步化 # 前端扣 Redis 库存——返回抢购成功给用户——MQ 异步写入 MySQL# 用户不等待 MySQL 写入完成——体验极快——但对一致性有风险3.3 测试验证# 1. 热点行注入测试python3 hot_row_storm.py# 预期128 并发时 P99 100ms锁竞争# 2. IO 抖动下 TPS 变化# 预期fio 运行期间 TPS 下降 50%# 3. 连接泄漏测试python3 connection_leak_storm.py# 预期第 501 个连接被拒绝max_connections500# 4. 验证监控告警触发# 在有 prometheus alertmanager 的环境中# 查看 alertmanager 是否收到了以下告警# - MySQLHighConnections连接使用率 80%# - MySQLLowBpHitRateBP 命中率 95%# - MySQLSlowQueries慢查询骤增4. 项目总结优点 缺点维度优点缺点/局限热点行拆分并发度线性提升N 桶 N 倍吞吐库存汇总查询复杂——跨桶聚合慢限流降级保护数据库不被突发流量打垮——快速失败优于超时等待用户体验受影响——提示系统繁忙异步化前端极快 5ms——数据库平缓写入一致性风险——MQ 丢消息导致少卖/多卖混沌工程提前发现系统薄弱点——6 维度故障注入需要独立的演练环境——不影响生产适用场景秒杀/大促热点行拆分 限流 异步化——三重保护。云环境定期注入 IO 抖动——验证云磁盘突发性能耗尽时业务降级是否生效。微服务架构模拟某个服务连接泄漏——验证隔离机制。双十一备战提前 1 个月——每周一次全链路故障演练。SRE 团队混沌工程作为日常 SRE 工作的一部分——持续验证系统韧性。不适用场景小型项目混沌工程的投入产出比较低——先做好监控和告警。非生产环境未见问题先在测试环境复现故障——确认解决方案有效——再在生产环境演练。注意事项混沌工程必须在有完备监控的环境下进行注入了故障但不知道系统有什么反应 盲测。热点行拆分后——库存查询必须跨桶汇总相比单行查询慢了 N 倍——需要用缓存。异步化的 MQ 消息必须带幂等键消费者重试时——MySQL 写入不能重复扣减。常见踩坑经验故障案例一热点行拆分后——库存还剩 5 个但显示 0——“少卖”。根因每个桶剩余 0-1 库存——但没有任何一个桶的库存 2——扣减 2 个失败。修复扣减时支持跨桶——或增加库存碎片重分配机制。故障案例二IO 抖动注入用的 fio 文件和数据文件在同一磁盘——MySQL 无法区分——所有 IO 都慢。根因这是预期行为——混沌工程的目的就是验证最坏情况。修复发现单磁盘不足以隔离 IO——迁移 binlog 到独立磁盘。故障案例三限流器的令牌速率设得太低——正常用户也被拒绝——推广活动效果打折。根因未区分正常用户下单和机器人刷单——一刀切限流。修复引入用户行为分析——对恶意流量按 IP / UserID 限流——正常用户放行。思考题热点行拆分后——如何在不扫描所有桶的情况下——快速回答这个商品还剩多少库存为什么异步化方案Redis 扣减 MQ 写入 MySQL中——MQ 必须保证 at-least-once 投递如果投递了两次——MySQL 侧怎么保证不重复扣减答案提示第 1 题——用 Redis 维护总库存的实时缓存原子 DECR 更新MySQL 仅用于持久化和对账第 2 题——MQ 可能因为超时重试导致投递两次——MySQL 侧用流水表的唯一键(order_id, sku_code, flow_type)实现幂等——重复消费时直接返回成功。延伸阅读与资源10倍开发者的 Dify 魔法书从零构建全栈 AI 应用后端工程师转型AI第一课-Ollama 与私有化大模型实战大型语言模型(LLM) vLLM 高性能推理落地实战Agent开发之LlamaIndex 实战修炼与源码进阶大语言模型Transformers 实战修炼与源码剖析
