1 高并发对数据库产生的压力
2 竞争状态下如何解决库存的正确减少("超卖"问题)
对于第一个问题,已经很容易想到用锁表来处理抢购,但是锁表漏洞是 假设一个用户出现问题程序就不能接着运行了 ,例如使用Redis。
重点在于第二个问题
模拟高并发现象可参考 http://blog.csdn.net/nuli888/article/details/51865401
- <?php
- $conn=mysql_connect("localhost","big","123456");
- if(!$conn){
- echo "connect failed";
- exit;
- }
- mysql_select_db("big",$conn);
- mysql_query("set names utf8");
- $price=10;
- $user_id=1;
- $goods_id=1;
- $sku_id=11;
- $number=1;
- //生成唯一订单
- function build_order_no(){
- return date('ymd').substr(implode(NULL, array_map('ord', str_split(substr(uniqid(), 7, 13), 1))), 0, 8);
- }
- //记录日志
- function insertLog($event,$type=0){
- global $conn;
- $sql="insert into ih_log(event,type)
- values('$event','$type')";
- mysql_query($sql,$conn);
- }
- //模拟下单操作
- //库存是否大于0
- $sql="select number from ih_store where goods_id='$goods_id' and sku_id='$sku_id'";//解锁 此时ih_store数据中goods_id='$goods_id' and sku_id='$sku_id' 的数据被锁住(注3),其它事务必须等待此次事务 提交后才能执行
- $rs=mysql_query($sql,$conn);
- $row=mysql_fetch_assoc($rs);
- if($row['number']>0){//高并发下会导致超卖
- $order_sn=build_order_no();
- //生成订单
- $sql="insert into ih_order(order_sn,user_id,goods_id,sku_id,price)
- values('$order_sn','$user_id','$goods_id','$sku_id','$price')";
- $order_rs=mysql_query($sql,$conn);
- //库存减少
- $sql="update ih_store set number=number-{$number} where sku_id='$sku_id'";
- $store_rs=mysql_query($sql,$conn);
- if(mysql_affected_rows()){
- insertLog('库存减少成功');
- }else{
- insertLog('库存减少失败');
- }
- }else{
- insertLog('库存不够');
- }
- ?>
测试数据表
cmd中测试 apache中自带的压力测试器ab apache/bin/ab.exe
模拟5000高并发测试
webbench -c 5000 -t 60 http://192.168.1.198/big/index.php
ab -r -n 6000 -c 5000 http://192.168.1.198/big/index.php
总结来说 ,解决高并发的所有方式
1.可以给语句加行锁 但是这种方式会造成数据库的压力(压力特别大)
2.因为超卖会是造成数据库中的记录变为负数 所以我们可以想到将这个字段的数据类型设置为不能为负数 所以当超卖时会报错因而阻止超卖 但是缺点是会报错从而影响用户的体验
3.使用文件排他锁
4.使用redis
5.可以使用rabbitMQ消息对列
优化方案1:将库存字段number字段设为unsigned,当库存为0时,因为字段不能为负数,将会返回false。
缺点是:如果出现超卖情况就会报错对于用户体验来说不好
优化方案2:悲观锁,也就是在修改数据的时候,采用锁定状态,排斥外部请求的修改。遇到加锁的状态,就必须等待。
优化方案3:使用MySQL的事务,锁住操作的行采取FIFO队列思路(我们直接将请求放入队列中,采用FIFO(First Input First Output,先进先出),这样的话,我们就不会导致某些请求永远获取不到锁。看到这里,是不是有点强行将多线程变成单线程的感觉哈。)
缺点:但是,系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说,队列内的请求会越积累越多,最终Web系统平均响应时候还是会大幅下降,系统还是陷入异常。
优化方案4:使用非阻塞的文件排他锁(乐观锁思路)这个数据所有请求都有资格去修改,但会获得一个该数据的版本号,只有版本号符合的才能更新成功,其他的返回抢购失败。这样的话,我们就不需要考虑队列的问题,不过,它会增大CPU的计算开销。但是,综合来说,这是一个比较好的解决方案。
缺点:会增大CPU的计算开销
优化方案5:Redis中的watch