并发请求导致的业务处理安全风险及解决方案

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时，同时有多个请求，而当前没有一个请求走到商品库存减少位置，多次购买都能成功，而商城却无货可发。

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

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

文章目录