mysql去掉秒杀场景_秒杀场景下mysql减库存逻辑优化

【问题背景】

某天早上做活动，流量大量增长，导致大量更新库存操作失败。

操作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)继续；否则处理下一个item

=>=>更新库存

=>=>更新是否售空

=>=>插入

=>所有分库，每个分库均提交事务

1)如果有一个item更新失败，回滚所有事务

2)尽量保证要不所有item都更新成功，要不都失败

问题

1)一个事务中，sql操作太多；如果事务中有update操作，则从update操作执行到事务提交将会一直锁住操作行，因此事务越长，锁越长，性能损耗越大

2)每个分库都要等所有item更新完后才提交，增长事务时间(也就是锁时间)

【优化后】

如果需要更新 item1(分库1)、item2(分库2)、item3(分库4)的库存

流程

=>循环在每个item所在分库对item进行处理

=>=>在分库1中开启事务

=>=>插入seq表

=>=>更新库存and是否售空

=>=>提交事务

问题

1)一次操作多个item时，不保证要不都成功，要不都失败

2)只要有sql操作失败，就返回失败

【对比】

原文：http://www.cnblogs.com/taoxinrui/p/6399691.html