谈谈死锁之三 秒杀场景下开源MySQL性能压测对比

MySQL的热点更新场景，对应到业务场景是秒杀系统，热点商品减库存。

MySQL5.7 2016年底发布了GA版本,但大部分公司线上用的还是5.6的版本.Facebook的MyRocks也是基于5.6进行开发,MyRocks未来也直接合并到8.0。

我们今天的分享是基于MySQL5.6.19和Percona5.6.25来进行讨论.

我们对这两个版本，进行了MySQL源码的修改，从Facebook 5.6开源版本里面抽取了关闭死锁检测的补丁，合并到了MySQL5.6.19和Percona5.6.25，并进行了性能压测。

性能压测主要是进行了四个配置的对比

A.MySQL5.6.19 原生版本

B.MySQL5.6.19 增加死锁检测关闭 （5.6.1.9+no deadlock check ndlc)

C.Percona5.6.25 原生版本 (percona+tp)

D.Percona5.6.25增加死锁检测关闭 (percona+tp+nldc)

对着四个版本进行了8，16，32，64，128，512，1024，2048，4096个并发线程的压测

压测准备

压测工具 sysbench0.5

事务隔离级别均为READ-COMMITTED.  CPU 32cores. BP15G。数据放在SSD，日志放在SAS盘。

表结构和数据准备:由于秒杀和减库存重要的瓶颈之一是在update语句的效率，我们为了简单理解起见，用一个最核心的update语句来做事务

Percona 线程池参数:set global thread_pool_size=16;set global thread_pool_oversubscribe=1;set global innodb_thread_concurrency=32;

CREATE TABLE `test_update` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`stock` int(11) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8

insert into item.test_update (id,stock) value(1,500000);

更新语句

update test_update set stock =stock -1  where id = 1 and stock >3;

8个客户端下，原生版本的TPS比后面三个场景的TPS要高.但这么少的连接，业务很难会只给这么少连接

16个客户端连接下，原生版本TPS最高

32个客户端连接下，原生版本TPS最高

64个客户端连接下，原生版本+关闭死锁检测 TPS最高

128个客户端连接下，原生版本+关闭死锁检测 TPS最高

256个客户端连接下，原生版本+关闭死锁检测 TPS最高，原生版本的TPS已经降低到2000+

512个客户端连接下，5.6.19TPS降低到600+

1024个客户端连接下，5.6.19TPS降低到30

版本	客户端连接	TPS
A 5.6.19	256	2271.91
B 5.6.19+ndlc	256	9198.25
C percona+tp	256	7925.89
D percona+tp+ndlc	256	8229.47
版本	客户端连接	TPS
A 5.6.19	512	646.53
B 5.6.19+ndlc	512	6225.06
C percona+tp	512	7587.56
D percona+tp+ndlc	512	7608.73
版本	客户端连接	TPS
A 5.6.19	1024	30
B 5.6.19+ndlc	1024	3924.82
C percona+tp	1024	6717.44
D percona+tp+ndlc	1024	6925.37

压测结论

1.关闭死锁检测后，5.6.19版本在1024个客户端并发连接情况下可以从30TPS提升到3924，应用程序无须更改代码，减库存性能提升120倍

2.Percona版本由于有线程池做了一层连接的并发控制，间接减少了数据库内部的线程上下文切换和锁竞争，在1024个客户端并发连接的情况下，TPS是5.6.19+关闭死锁检测的接近1倍。

3.Percona版本+线程池调优+关闭死锁检测的情况下，在1024个客户端并发连接下，性能有小幅度提升

4.5.6.19版本，谨慎考虑可以只增加关闭死锁检测的补丁代码，实现最小风险升级。但在微服务架构下，客户端对DB的链接越来越多，建议最终升级成Percona版本，利用线程池的优势来提升DB的稳定性。