何登成-库存热点更新. 有补充语音笔记

from

【阿里在线技术峰会】何登成：AliSQL性能优化与功能突破的演进之路

https://yq.aliyun.com/articles/57900

同系列,配合起来看,秒杀场景下MySQL的低效--原因和改进.pdf

库存热点更新

“双十一”时，有很多商品是大家都想去抢购的，库存在数据库内部只是一行标识商品剩余件数的记录，买商品的行为其实是大家在并发的扣减商品记录。当我们并发的去扣减记录的时候，为了保证正确性，一定要对这条记录加锁，由于锁的存在，就把商品扣减变成了一个串行的过程。这个问题与之前问题的不同之处是，这个问题是很多用户去抢一个热点商品所带来的问题。

先把它做成一个简化的模型，先开始一个事务，对它做一个插入，更新热点行，读出热点行的后项，最后进行提交。其中，更新热点行需要加锁，提交的时候放锁。MySQL会出现排队等锁的过程，并且每次排队都会进行死锁检测，这样逐渐使得死锁检测时间越来越长。

第一版做了一个很简单的优化，由于很多线程进入到数据库，但是又无事可做，所以控制进入数据库的线程数，保证InnoDB中有固定数目的线程，这样会使死锁检测、线程切换时间等都急剧下降。控制数量的伪串行化.  

     继续分析该模型，持有锁的时间是从第三步开始，第五步结束，这个过程中有两个网络交互时间。考虑到降低网络交互时间，把第三步和第四步合并，先对热点行进行更新，更新完之后顺便把热点行返回给应用服务器。在此基础上，再考虑继续减少网络交互时间，把三四五步都合并。更新库存时，如果更新到了一行，并且更新后项也满足，就直接把这个事务提交；如果说这里面的逻辑不满足，则自动把事务回滚掉。这样一来，所有持有锁的SQL都在数据库内部，没有任何网络交互。

     继续分析该模型，持有锁的时间是从第三步开始，第五步结束，这个过程中有两个网络交互时间。考虑到降低网络交互时间，把第三步和第四步合并，先对热点行进行更新，更新完之后顺便把热点行返回给应用服务器。在此基础上，再考虑继续减少网络交互时间，把三四五步都合并。更新库存时，如果更新到了一行，并且更新后项也满足，就直接把这个事务提交；如果说这里面的逻辑不满足，则自动把事务回滚掉。这样一来，所有持有锁的SQL都在数据库内部，没有任何网络交互。

       既然串行已经优化到了一定的极致，能不能把所有穿行的用户请求做一个batch合并？怎么演进？用户发SQL过来后，对热点记录做哈希(sql服务层是否已经知道是否同一行. 用hint来标识业务场景,对应不同的代码逻辑.见另外一篇文章, <<秒杀场景下MySQL的低效--原因和改进.pdf>> 这样分层,简化分析逻辑.)，其中每一个桶是一个热点行，对每个桶做收集，然后由桶里面的第一个事务一批次的把当前桶里收集的所有扣减请求全部一次性提交掉，这样虽然仍旧是串行化，但是用批处理去做了。为了提升整体性能，当第一批提交的时候第二批开始收集，(类似与mysql的 group commit) ,来回滚动,这样就将单线程的串行变成了批处理的串行。

   然后测试验证,加了个参数,0.1毫秒的等待然后提交. 前面提到了串行化0.2毫秒.总共0.3毫秒.批处理,每次处理20个. 1秒/0.3毫秒*20=6w个sql请求.