转载

秒杀应用的MySQL数据库优化

关于秒杀

随着双11活动的不断发展，小米饥饿营销模式的兴起，“秒杀”已经成为一个热点词汇。在一些活动中，热销商品会以惊人的速度售罄，比如最近Inside君在抢购美图M4手机，12点开卖，1分钟之内就被售罄。

秒杀的实现

对于关注数据库的Inside君来说，更关心的是如何高效的实现秒杀应用。之前淘宝在2013年的数据库大会上分享过他们的秒杀方案，修改MySQL数据库源码来实现高效的秒杀应用。但是，那篇分享过于高大上，没有给出具体的实现过程。另外，从其他渠道打听到的是这个方案并没有在生产环境上线，不知道有没有其他知道内幕的小伙伴，具体来说说淘宝的方案是否有上线。

当然，有多种方法来优化秒杀应用，比如使用memcached的CAS功能，redis的原子操作，但是 这些优化方法都无法实现事务的特性 。对于深受Jim Gray事务处理教育长大的一代，Inside君觉得任何事情都应该事务的，不支持事务只不过能取得暂时的胜利，整个世界的哲学应该就是事务，即要么全做，要么全不做，不要处于一个中间状态。Inside君的为人哲学就是，要么不去设定一个目标，否则这个目标一定会去实现。比如，Inside君决定去读个博，那么就一定会完成这个学业。

Inside君感觉虽然淘宝没有给出具体的实现方式，但是抛出了秒杀应用对于数据库压力的问题所在，即大并发量下更新同一行数据的压力。例如并发执行如下的SQL语句模拟秒杀场景：

<br />BEGIN;<br />INSERT INTO stock_log VALUES<br />SELECT count FROM stock WHERE id=1 AND count>0 FOR UPDATE;<br />UPDATE stock SET count = count -1 WHERE id=1 AND count>0;<br />COMMIT;<br />

在做秒杀时，最主要是对库存表进行操作，在操作前可能需要插入一些其他操作，比如日志等，然后就是对库存表进行更新。下图显示增大并发量的情况下，事务处理的性能：

秒杀应用的MySQL数据库优化

显而易见的是随着并发量的增大，事务处理的性能越差。这和淘宝之前分享的数据基本一致。导致其中的原因就是秒杀是对同一件商品进行更新，需要对同一行记录加锁，因此 秒杀操作虽然是并行的，但是在数据库层面是串行的 。

随着并发的不断增大，不断发生事务的锁等待与唤醒操作，导致性能的急剧下降。如果通过perf工具来观察的话，应该可以观察到类似如下的内容：

<br />#<br /><strong><span style="color: #ff0000;">59.06% mysqld mysqld [.] lock_deadlock_recursive</span></strong><br />16.63% mysqld libc-2.13.so [.] 0x115171<br />3.09% mysqld mysqld [.] lock_rec_get_prev<br />2.96% mysqld mysqld [.] my_strnncollsp_utf8<br />......<br />

可以发现锁的死锁检测占据了大部分的CPU时间，究其原因，就是因为锁等待。

innodb_thread_concurrency

有小伙伴或许会知道可以通过innodb_thread_concurrency参数来控制InnoDB存储引擎层的并发量。的确，通过这个参数可以限制进入InnoDB引擎层的事务数量，对比测试的话，性能上的确会有一定的提升：

秒杀应用的MySQL数据库优化

可以发现，将innodb_thread_concurrency设置为16，性能的确会有一定的提升。并发线程数在128的时候，TPS从原有的4300提升为了7200，将近有65%的性能提升。但是在256线程之后，性能依旧堪忧。

导致上述的原因是虽然在InnoDB存储引擎层做了“限流”，但是MySQL数据库上层的线程依然需要等待唤醒。

线程池技术

业界提供了很多关于秒杀MySQL的解决方案，然而非常的定制化，并且需要应用修改相信的程序，比如通过在SQL语句中写hint来进行排队，而这种的排队机制在我看来在低并发量下性能反而又会变差。因此，一个通用的解决方案是采用线程池技术。

线程池可以在MySQL上层限制住同时运行的MySQL的事务数，这样就解决了由秒杀而导致的资源竞争问题。例如，通过前面的测试，已经得知并发16线程时，秒杀可以有最好的性能，那么这时用户将线程池的大小设置为16，这样就能获得用户预期想要的性能：

秒杀应用的MySQL数据库优化

可以发现即使在4096个并发线程下，秒杀依然可以有近10000的TPS。通过线程池技术，秒杀就是这么简单，无需任何应用端的修改。

但是线程池这里有个参数thread_pool_oversubscribe，这个参数其实有点类似云计算中“超售”概念，即MySQL的线程池允许有额外的线程运行。该参数默认是3，之前thread_pool_size设置为16，那么总共允许16*（1+3）=64个线程同时运行。这个参数的默认值本身没有问题，但是对于秒杀应用来说确是不需要的，因为之前已经讨论过，秒杀应用是串行的。所以将参数thread_pool_oversubscribe设置为1，秒杀应用还能有进一步的提升：

秒杀应用的MySQL数据库优化