【问题背景】
某天早上做活动，流量大量增长，导致大量更新库存操作失败。
操作mysql返回的错误均为“Lost Connection to mysql server”，即mysql服务端主动断开了连接，导致update操作失败。
都是在sql执行过程中返回的“Lost”，且都是update操作返回“Lost”，同一时刻的“select”操作并无异常。
都是update执行操过了1s后返回的“Lost”
【原因】
秒杀情景下是大量update同时操作同一表的同一记录
对同一记录的写操作都要加“行锁”，且有“死锁检测”，使得sql操作串行执行，有阻塞
猜测：某些请求由于等到超时了，被mysql服务关了连接
【老流程】
如果需要更新 item1（分库1）、item2（分库2）、item3（分库4）的库存
- 流程
=>所有分库，每个分库上均开启一个事务
=>查询。。
=>循环处理3个item
=>=>如果该次操作以前没做过（没有对应<seqid,itemid>）继续；否则处理下一个item
=>=>更新库存
=>=>更新是否售空
=>=>插入<seqid/item>
=>所有分库，每个分库均提交事务
1）如果有一个item更新失败，回滚所有事务
2）尽量保证要不所有item都更新成功，要不都失败
- seq表
每次的请求对应一个唯一的seqid，而<seqid,itemid>记录了这次请求的item是否更新成功。
如果seq表中有这条记录表示上次请求的item以更新成功。
目的是为了防止由于上次操作成功，而返回结果时出现问题，下次重试导致重复的执行。
- 问题
1）一个事务中，sql操作太多；如果事务中有update操作，则从update操作执行到事务提交将会一直锁住操作行，因此事务越长，锁越长，性能损耗越大
2）每个分库都要等所有item更新完后才提交，增长事务时间（也就是锁时间）
【优化后】
如果需要更新 item1（分库1）、item2（分库2）、item3（分库4）的库存
- 流程
=>循环在每个item所在分库对item进行处理
=>=>在分库1中开启事务
=>=>插入seq表<seq,item1>
=>=>更新库存and是否售空
=>=>分库1中提交事务
=>=>分库2。。中操作item2
=>=>分库4。。中操作item3
- 更改
1）并没有在所有分库中新起事务，而是每个事务中只处理自己所包含的item的减库存操作；当一次请求多个item时，减少每个库的事务的时间长度
2）先插入seq表，再更新库存，如果插入失败直接退出；减少一次读seq操作，将事务中sql操作减到最少
- 问题
1）一次操作多个item时，不保证要不都成功，要不都失败
2）只要有sql操作失败，就返回失败
【对比】
