秒杀场景下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,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操作失败,就返回失败

【对比】

 

posted @ 2017-02-14 23:41  小树桩的朋友  阅读(1820)  评论(0编辑  收藏