文档章节

“秒杀”问题的数据库和SQL设计

汪纬
 汪纬
发布于 2015/05/06 15:55
字数 2468
阅读 39
收藏 1
点赞 0
评论 0

问题的来源

上篇文章介绍了 ETL 场景下的高性能高一致性解决方案,这次的问题也是一个常见的问题。

最近发现很多人被类似秒杀这样的设计困扰,其实这类问题可以很方便地解决,先来说说这类问题的关键点是什么:

  1. 一定要高性能,不然还能叫秒杀吗?

  2. 要高一致性,库存只有100个,不能卖出去101个吧?但是库存10000实际只卖了9999是否允许呢?

  3. 既然这里说了是秒杀,那往往还会针对每个用户有购买数量的限制。

总结一下,还是那几个词:高性能高一致性!

下文的所有解决方案是在 Mysql InnoDB 下做的。因为用到了很多数据库特性。其他的数据库或其他的数据库引擎会有不同的表现,请注意。

 

完全不考虑一致性的方案

表结构

+-----------+------------------+------+-----+---------+----------------+
| Field     | Type             | Null | Key | Default | Extra          |
+-----------+------------------+------+-----+---------+----------------+
| id        | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id   | int(11)          | NO   |     | NULL    |                |
| deal_id   | int(11)          | NO   |     | NULL    |                |
| buy_count | int(11)          | NO   |     | NULL    |                |
+-----------+------------------+------+-----+---------+----------------+

 

方案

表结构很简单,其实就是一个userdeal的关联表。谁买了多少就插入数据呗。

首先,还要检查一下传过来的buy_count是否超过单人购买限制。

接下来,每次插入前执行以下以下操作检查一下是否超卖即可:

select sum(buy_count) from UserDeal where deal_id = ?

最后还要检查一下这个用户是否购买过:

select count(*) from UserDeal where user_id = ? and deal_id = ?

全都没问题了就插入数据:

insert into UserDeal (user_id, deal_id, buy_count) values (?, ?, ?)

 

存在的问题

大家别笑,这样的设计你一定做过,刚毕业的时候谁没设计过这样的系统啊?而且大部分系统对性能和一致性的要求并没有那么高,所以以上的设计方案还真是普遍存在的。

那就说说在什么情况下会出问题吧:

  1. 如果库存只剩一个,两个用户同时点购买,两个人检查全部成功,最后,就超卖了。

  2. 如果一个用户同时发起两次请求,检测部分同样可能会同时通过,最后,数据就异常了。

那就让我们一步步来解决里面存在的问题吧。

 

保证单用户不会重复购买

先来解决最简单的问题,保证单用户不会重复购买。

其实只要利用数据库特性即可,让我们来加一个索引:

alter table UserDeal add unique user_id_deal_id(user_id, deal_id)

加上唯一索引后,不仅查询性能提高了,插入的时候如果重复还会自动报错。

当然别忘了在业务代码中 catch 一下这个异常,并在页面上给用户友好的提醒。

 

解决超卖问题

方案

为了解决这个问题,第一个想到的就是把这几次操作在事务中操作。否则无论怎么改,也都不是原子性的了。

但是加完事务后就完了?

上面的select语句没有使用for update关键字,所以就算加入了事务也不会影响其他人读写。

所以我们只要改一下select语句即可:

select sum(buy_count) from UserDeal where deal_id = ? for update

 

优化

刚改完后发现,问题解决了!so easy!步步高点读机,哪里不会点哪里,so easy!

但是不对啊!为什么两个用户操作不同的deal也会相互影响呢?

原来我们的select语句中的查询条件是where deal_id = ?,你以为只会锁所有满足条件的数据对吧?

但实际上,如果你查询的条件不在索引中,那么 InnoDB 会启用表锁!

那就加一个索引呗:

alter table UserDeal add index ix_deal_id(deal_id)

 

提高性能了

好了,到目前为止,无论用户怎没点,无论多少个人买同一单,都不会出现一致性的问题的。

而且事务都是行锁,如果你的业务场景不是秒杀,操作是分散在各个单子上的。而且你的压力不大,那么优化到这就够了。

但是,如果你真的会有几万人、几十万人同时秒杀一个单子怎么办?

很多交易类网站都会有这样的活动。

 

我们现在思考一下,上面的优化好像已经是极致了,不仅满足了一致性,而且性能方面也做了足够的考量,无从下手啊!

这时候,只能牺牲一些东西了。

 

鱼与熊掌不可兼得

优化的思路

性能和一致性常常同时出现,却又相互排斥。刚才我们为了解决一致性问题带入了性能问题。现在我们又要为了性能而牺牲一致性了。

这里想提高性能的话,就要去掉事务了。那么一旦去掉事务,一致性就没办法保证了,但有些一致性的问题并不是那么地严重。

所以,这里最关键的就是要想清楚,你的业务场景对什么不能容忍,对什么可以容忍。不同业务场景最后的方案一定是不同的。

 

秒杀可以容忍什么

本文标题说的是秒杀,因为这个业务场景很常见,那么我们就来说说秒杀。

秒杀最怕的是超卖,但却可以接受少卖。什么是少卖?我有一万份,卖了9999份,但数据库里却说已经买完了。

这个严重吗?只要我们能把这个错误的量控制在一定比例以内并且可以后续修复,那这在秒杀中就不是一个问题了。

 

为了性能牺牲一致性的设计方案

去掉了事务会发生什么

在上述的方案中,如果去掉了事务,单用户重复购买是不会有问题的,因为这个是通过唯一索引来实现的。

所以这边我们主要是去解决超卖问题。

既然去掉了失误,那么for update琐行就无效了,我们可以另辟蹊径,来解决这个问题。

 

修改表结构

刚才一直没有提Deal表,其实它就是存了一下基本信息,包括最大售卖量。

之前我们是通过对关联表进行sum(buy_count)操作来得到已经卖掉的数量的,然后进行判断后再进行插入数据。

现在没了事务,这样的操作就不是原子性的了。

所以让我们来修改一下Deal表,把已经售卖的量也存放在Deal表中,然后巧妙地把操作转换成一行update语句。

+-----------+------------------+------+-----+---------+----------------+
| Field     | Type             | Null | Key | Default | Extra          |
+-----------+------------------+------+-----+---------+----------------+
| id        | int(11) unsigned | NO   | PRI | NULL    | auto_increment |
| buy_max   | int(11)          | NO   |     | NULL    |                |
| buy_count | int(11)          | NO   |     | NULL    |                |
+-----------+------------------+------+-----+---------+----------------+

 

修改执行过程

如果你继续先把数据查出来到内存中然后再操作,那就不是原子性的了,必定会出问题。

这时候,神奇的update语句来了:

update Deal set buy_count = buy_count + 1 where id = ? and buy_count + 1 <= buy_max

如果一单的buy_max是1000,如果有2000个用户同时操作会发生什么?

虽然没有事务,但是update语句天然会有行锁,前1000个用户都会执行成功,返回生效行数1。而剩下的1000人不会报错,但是生效行数为0。

所以程序中只要判断update语句的生效行数就知道是否抢购成功了。

 

还没有结束

问题解决了?好像也没牺牲一致性啊,用户根本不会超卖啊?

但是,购买的时候有两个关键信息,“剩余多少”和“谁买了”,刚才的执行过程只处理了第一个信息,它根本没存“谁买了”这个信息。

而这两个信息其实也是原子性的,但是为了性能,我们不得不牺牲一下了。

刚才说到如果update的生效行数是1,就代表购买成功。所以,如果一个用户购买成功了,那么就再去UserDeal表中插入一下数据。

可如果一个用户重复购买了,那么这里也会出错,所以如果这里出错的话还需要去操作一下Deal表把刚才购买的还回去:

update Deal set buy_count = buy_count - 1 where id = ? and buy_count - 1 >= 0

这边理论上不会出现buy_count - 1 < 0的情况,除非你实现的不对。

…… 无图无真相,完全混乱了

只看文字不清晰,还是来张完整的流程图吧!

flow1

毫无破绽啊!不是说要牺牲一致性吗?为什么没看到?因为上面的流程图还没有考虑数据库故障或者网络故障,最后还是来一张最完整的流程图吧:

flow2

仔细看一下整张流程图,最终就这几种情况:

  1. 执行成功

  2. 无库存

  3. 回滚成功

  4. 损失库存

前三种是正常的,只有“损失库存”是有问题的。其实,“损失库存”这种情况其实很难出现,只有在网络故障或者数据库的情况下才可能偶尔。

那你的业务可以容忍它吗?最终还是具体问题具体分析了。

 

不要过度优化

最后还是提醒一句,千万不要过度优化,第一个使用事务的方案其实已经够好了!

除非你的业务特殊,全中国几十万人几百万人会同时来买,那才有必要牺牲一下一致性提升性能。

对了,如果是像双十一或者小米这样子的抢购,上面的方案也是不够的…


本文转载自:

共有 人打赏支持
汪纬

汪纬

粉丝 11
博文 633
码字总数 32444
作品 0
上海
后端工程师
淘宝大秒系统设计详解

大家还记得2013年的小米秒杀吗?三款小米手机各11万台开卖,走的都是大秒系统,3分钟后成为双十一第一家也是最快破亿的旗舰店。经过日志统计,前端系统双11峰值有效请求约60w以上的QPS ,而后...

陶邦仁
2016/03/14
524
1
热点推荐:秒杀系统架构分析与实战

1 秒杀业务分析 正常电子商务流程(1)查询商品;(2)创建订单;(3)扣减库存;(4)更新订单;(5)付款;(6)卖家发货 秒杀业务的特性(1)低廉价格;(2)大幅推广;(3)瞬时售空;(...

洋哥6
2016/04/14
359
1
关于并发、超卖处理的思路

做电商网站,经常会有各种秒杀和热门商品,所以高并发的处理一直是电商最重要的事情。这里记录下当初自己是如何处理的 写在前面: 1、本文设计到的并发处理均是针对纵向,不针对横向扩展,即...

卖小女孩的小火柴
2015/10/13
4.8K
6
2012 DTCC:海量数据处理与Hadoop应用

【IT168 现场报道】2012年4月13日,由IT168(ITPUB、IXPUB、ChinaUnix)主办的2012中国数据库技术大会(DTCC)在北京隆重召开。大会第三天,以“海量数据处理与Hadoop应用”为主题的圆桌讨论拉开...

it168网站
2012/04/15
0
0
微信高并发资金交易系统设计方案——百亿红包背后的技术支撑

作者|方乐明 编辑|尾尾每年节假日,微信红包的收发数量都会暴涨,尤以除夕为最。如此大规模、高峰值的业务需要,背后需要怎样的技术支撑?百亿级别的红包规模,如何保证并发性能与资金安全...

umgsai
2017/09/26
0
0
JavaWeb秒杀业务场景设计

秒杀业务场景设计问题经常被面试的时候被问到,在实际业务中,也常常需要实现,下面我们来看看如何实现秒杀业务. 秒杀业务,是典型的短时大量突发访问类问题 特点: 秒杀时网站的访问量大增; 秒杀...

小红牛
06/11
0
0
秒杀系统架构优化思路

转载 2016-04-06 58沈剑 架构师之路 本文曾在“架构师之路”上发布过,近期支援Qcon-AS大会,在微信群里分享了该话题,故对原文进行重新整理与发布。 一、秒杀业务为什么难做 1)im系统,例如...

xiaolyuh
2017/09/18
0
0
[转]秒杀业务架构优化之路

原文地址:http://www.infoq.com/cn/articles/flash-deal-architecture-optimization 一、秒杀业务为什么难做 IM系统,例如QQ或者微博,每个人都读自己的数据(好友列表、群列表、个人信息)...

风间影月
2016/03/29
0
0
秒杀系统架构优化思路

一、秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表、群列表、个人信息); 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据; 3)秒杀系统,...

Candy_Desire
2016/04/07
1K
0
专访丁奇:阿里云即将开源AliSQL,针对秒杀优化

8月9日,在2016云栖大会·北京峰会上,阿里云宣布启动AliSQL数据库开源项目。预计在9月份邀请部分用户内测,预计在10月份,开发者阿里云Code平台和GitHub网站上可以下载AliSQL,感兴趣的读者...

局长
2016/09/02
7.9K
28

没有更多内容

加载失败,请刷新页面

加载更多

下一页

打印斐波那契数

package com.jerry.ch04;public class PrintFibonacci {public static void main(String[] args) {for (int i=0; i<10; i++) {System.out.print(fib(i) + " ");}......

JerryNing
8分钟前
0
0
shell编程

一、shell脚本介绍

人在艹木中
9分钟前
0
0
istio 0.8 遥测 案例

==============遥测===================================== 演示如何从网格中收集遥测信息。 分布式跟踪。如何配置代理以向Zipkin或Jaeger发送跟踪请求 收集度量标准和日志。此任务说明如何配...

xiaomin0322
11分钟前
0
0
ND4J求多元线性回归以及GPU和CPU计算性能对比

上一篇博客《梯度下降法求多元线性回归及Java实现》简单了介绍了梯度下降法,并用Java实现了一个梯度下降法求回归的例子。本篇博客,尝试用dl4j的张量运算库nd4j来实现梯度下降法求多元线性回...

冷血狂魔
12分钟前
0
0
springboot常用注解

@SpringBootApplication: 包含@Configuration、@EnableAutoConfiguration、@ComponentScan 通常用在主类上。 @Service: 用于标注业务层组件。 @RestController: 用于标注控制层组件(如strut...

GoldenVein
18分钟前
1
0
如何进行大数据的入门级学习?

不知道你是计算机专业应届生还是已经从业者。总之,有java基础的学生学习大数据会轻松很多,零基础的小白都需要从java和linux学起。 如果你是一个学习能力特别强,而且自律性也很强的人的话可...

董黎明
32分钟前
0
0
使用Parcelable传递复杂参数

最近做AIDL传递对象,对象必须实现Parcelable的方法才可以被传递。 @Override    public int describeContents() {//这个 默认返回0就行了。        return 0;    }    ...

火云
33分钟前
0
0
十大Intellij IDEA快捷键

Intellij IDEA中有很多快捷键让人爱不释手,stackoverflow上也有一些有趣的讨论。每个人都有自己的最爱,想排出个理想的榜单还真是困难。以前也整理过Intellij的快捷键,这次就按照我日常开发...

HJCui
43分钟前
0
0
word 使用mathtype 编写 数学公式

下载安装,这个链接命名。。。。 http://www.mathtype.cn/xiazai.html 安装之后会多出一个选项 使用内联方式插入图表 编写公式的界面 设置支持latex 语法 输入公式回车就可以看到结果...

阿豪boy
今天
0
0
Promise

定义 Promise是异步编程的一种解决方案,所谓Promise就是一个容器,里面保存着某个未来才会结束的事件(通常是一个一步操作)的结果。 特点: 2.1 对象的状态不受外界影响,三种状态pending...

litCabbage
今天
1
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部