Taobao's solution for concurrency updates scenarios.

1. InnoDB并发控制在密集型并发更
新下的问题
希羽hickey

2. InnoDB并发控制在密集型并发更新
下的问题
• 测试篇
– 双11的死锁开关补丁背景
– 双12的并发控制补丁性能
• 原理篇
– 原版的并发控制模型及特点
• 优化篇
– 一步步排查问题所在
• 问题篇
– 目前的并发控制补丁存在的问题

3. InnoDB并发控制在密集型并发更新
下的问题–测试篇(IC)
• 双11的解决方案：死锁开关补丁(4月份)

4. InnoDB并发控制在密集型并发更新
下的问题–测试篇(SB)

5. InnoDB并发控制在密集型并发更新
下的问题–测试篇(IC)
• 读：写：事务写 = 50：6：4

6. InnoDB并发控制在密集型并发更新
下的问题–原理篇
• 简易模型

7. InnoDB并发控制在密集型并发更新
下的问题–原理篇

8. InnoDB并发控制在密集型并发更新
下的问题–原理篇
正常的逻辑

9. InnoDB并发控制在密集型并发更新
下的问题–原理篇

10. InnoDB并发控制在密集型并发更新
下的问题–优化篇
在密集型的更新场景下, 性能非常差
将死锁开关补丁中增加的deadlock_detect设置为0时，即不检测死锁时

11. InnoDB并发控制在密集型并发更新
下的问题–优化篇
把delay干掉，perf top为（性能一般无影响）

12. InnoDB并发控制在密集型并发更新
下的问题–优化篇
展开lock_rec_has_to_wait_in_queue后

13. InnoDB并发控制在密集型并发更新
下的问题–优化篇

14. InnoDB并发控制在密集型并发更新
下的问题–优化篇

15. InnoDB并发控制在密集型并发更新
下的问题–优化篇

16. InnoDB并发控制在密集型并发更新
下的问题–优化篇
• 问题的本质为大量suspend线程导致的同一页
面上锁数量非常大，导致销相关函数的开销巨
大，引发性能急剧下降。
• 我们所做的改动的核心，就是控制因suspend
进入 srv_mysql_table 的线程数
• 思路1：
• 思路2：

17. InnoDB并发控制在密集型并发更新
下的问题–问题篇
• IC集群线上跑的补丁基本第二种思想实现，
在实战过程中遇到如下几个问题：
– 对大事务的支持性较差
• 双12晚高峰期, 搜索dump到主库dump数据虚惊一场。
（dump一个小时增量！）
– 对非事务场景的优化提升不及事务场景
• 优化性能提升只有后者的一半左右
– 动态开关不“完全”动态
• running<1000时线上可动态关闭或打开

18. InnoDB并发控制在密集型并发更新
下的问题–问题篇
• 优化无止境！
• 感谢：
– 数据库团队和测试组同学的共同努力，以及IC
业务同学的支持！