0x00 背景

一段简单的购买程序,看起来没有任何问题。

剩余余额、商品库存、购买权限等判断面面俱到,从头到脚包装的严严实实。

但是为何人一多就频频漏点呐?何解?

0x01 问题分析

还是以商城购买为例,商城网站是web程序和数据库两部分,业务处理流程:

用户金额是否大于商品价格—>商品库存是否充足—>购买操作:生成订单—>扣除用户金额—>商品库存减1

业务处理流程

流程的每一部分都是web与数据库打交道,查询或者操作数据库。

程序示例(PHP+MySQL)

$goods=$db->FirstRow("SELECT * FROM ".Tb('goods')." WHERE goods_id='{$goods_id}'");
if(empty($goods)) ShowError('商品不存在');
/* 金额是否充足 */
if($user->money<$goods['price'])  ShowError('金额不足,请充值');
/* 商品库存 */
if($goods['num']==0)  ShowError('库存不足');
/* 购买操作 begin */
//生成订单
CreateOrder($goods,$user,time());
$user->Update('money'=>$user->money-$goods['price']); //用户金额减少
$db->Execute("UPDATE ".Tb('goods')." SET num=num-1 WHERE goods_id='{$goods_id}'");//商品库存-1
ShowSuccess('购买成功');
/* 购买操作 end */

正常来看这个业务处理是没有问题的,下面想象下多人同时购买(并发请求,如秒杀活动)的情境可能会引发的问题?

如果一个用户同时有两次购买请求,一次购买已进行到添加订单但未扣除用户金额,另一次购买在第一步用户金额判断便不准确了。

当商品库存仅为1时,同时有多个请求,而当前没有一个请求走到商品库存减少位置,多次购买都能成功,而商城却无货可发。

2013122510574019546.png

总结来说,当有大量的购买操作同时进行,如果数据库的处理速度跟不上程序的请求速度,就会出现判断不准确的问题,造成用户以单个商品的金额购买多个商品、某些用户付款了但得不到商品等,算是一个安全风险。

0x02 解决方案:

核心思想:将一次业务处理流程(如购买操作)作为一个最小操作单元,同一时间只能有一个操作。

1. 整个操作加内存锁。如在memcache里,开始购买时设置购买状态为进行中,购买结束后清除购买状态,程序开始时即从memcache里判断是否有正在进行的购买操作,如有则退出。

2. 限制每个用户的购买间隔,如10秒内仅允许购买一次,最好也是放在内存里。

3. 当然,优化数据库及程序以加快处理速度也是有必要的。

解决方案程序示例(PHP+MySQL+Memcached)

/**
 * 通过memcache解决并发购买问题
 */
$goods=$db->FirstRow("SELECT * FROM ".Tb('goods')." WHERE goods_id='{$goods_id}'");
if(empty($goods)) ShowError('商品不存在');
$mmc=memcache_init();
$lastBuyTime=$mmc->get('lastBuyTime_'.$user->userId);
if($lastBuyTime>0 && $lastBuyTime>time()-10)  ShowError('10秒内只能进行一次购买');
$buying=$mmc->get('buying');
if($buying==1)  ShowError('有正在进行的购买,请稍候');
/* 金额是否充足 */
if($user->money<$goods['price'])  ShowError('金额不足,请充值');
/* 商品库存 */
if($goods['num']==0)  ShowError('库存不足');
/* 购买操作 begin */
//生成订单
CreateOrder($goods,$user,time());
$user->Update('money'=>$user->money-$goods['price']); //用户金额减少
$db->Execute("UPDATE ".Tb('goods')." SET num=num-1 WHERE goods_id='{$goods_id}'");//商品库存-1
/* 购买操作 end */
$mmc->set('buying',0);
$mmc->set('lastBuyTime_'.$user->userId,time());
ShowSuccess('购买成功');

[原文地址]

相关内容:

身为码农,为12306说两句公道话,前淘宝工程师发帖谈12306:几乎是奇迹!

如何让100个请求同时发生

一种可能的新的漏洞类型:大量并发连接可能导致数据库重复查询同一条件

由12306.cn谈谈网站性能技术

相关讨论:

ziwen | 2013/12/25 12:07

尼玛这应该算是逻辑漏洞吧....

园长 | 2013/12/25 12:10

业务逻辑缺陷,并发=RMB

wuxianjun | 2013/12/25 14:51

亲,下单、扣款、减库存在同一个事务里吗?

你这程序在高并发的情况下库存会出现超卖的情况。

blue | 2013/12/25 16:40

就是为了解决高并发带来的问题,下单、扣款、减库即使在一个事务里,未处理完时前面的判断也会被绕过,而且像一些通用的电商程序,因为不保证数据库是否支持事务而没有使用事务~

齐迹 | 2013/12/25 17:14

开启事务都是是会锁表的。理论上不存在绕过的可能。有一个情况我们之前遇到过 当查询的时候走的从库 会导致绕过。

wuxianjun | 2013/12/26 14:22

不同用户的情况下:

A线程 ----> 获取goods当时库存是10个,刚好执行到18行.

B线程 ----> 因为A线程执行18行,还没执行减少库存代码,B线程执行4行代码的时候从数据库获取goods的库存还是10个。

而这样的情况,假如A线程买了9个走了,实际库存只有一个,这样B线程获取的数据就有问题了。

这样会导致库存超卖。

nyannyannyan | 2013/12/30 22:05

加了独占锁...B线程想获取goods记录存必须wait....

这是教开发并发程序最开始教的producer-consumer模型...有一套很成型的semaphore的数据结构来解决

齐迹 | 2013/12/25 15:44

@blue mc 也是有可能延迟的 所以目前最好还是只能利用事务。

齐迹 | 2013/12/25 15:45

还有就是异步 用队列来实现。

blue | 2013/12/25 16:24

将操作都放到数据库里肯定最好,之前还看过一程序所有的操作都是存储过程,我这只是描述一种有安全风险的情况和能够快速部署的解决方案

小胖子 | 2013/12/25 22:05

用小米的方式来处理,哈哈哈,等你们先抢单,再支付,抢单成功的再支付,队列来解决这个问题。

Mr.Anderson | 2013/12/26 10:54

cool stuff.

zsmynl | 2013/12/26 16:33

学习,学习~

xsser | 2013/12/30 18:22

一看洞主就是吃过亏的人

_Evil | 2014/01/02 18:01

楼上也吃过短短的亏啊 忘记了?

clzzy | 2014/01/07 14:37

尼玛这应该算是逻辑漏洞吧....

乌帽子 | 2014/01/11 16:06

http://ww3.sinaimg.cn/bmiddle/53993e84jw1ecf2e1phf8j20c89zl7wi.jpg