Redis 并发原子性原理

             

Redis原子性原理

摘要:

1、Redis是单进程单线程的网络模型,用的是epoll网络模型,网络模型都是单线程异步非阻塞处理网络请求

2、Redis的单线程处理所有的客户端连接请求,命令读写请求。(有些任务比如rdb和aof等操作是fork子进程处理的,不会影响redis主线程处理客户端的命令)

3、Redis提供的所有API操作,相对于服务端方面都是one by one执行的,命令是一个接着一个执行的,不存在并行执行的情况。

4、Redis客户端就可能会出现高并发出现错误的读写数据,下面我们举个电商秒杀的例子来讲解一下。

Redis在并发中的表现

Redis的API是原子性的操作,那么多个命令在并发中也是原子性的吗?

看看下面这段代码:

<?php
 $num = 10; //系统库存量
 $user_id = \Session::get('user_id');//当前抢购用户id
 $len = \Redis::llen('order:1'); //检查库存,order:1 定义为健名
 if($len >= $num)
     return '已经抢光了哦';
 $result = \Redis::lpush('order:1',$user_id); //把抢到的用户存入到列表中
 if($result)
     return '恭喜您!抢到了哦';

如果代码正常运行,按照预期理解的是列表order:1中最多只能存储10个用户的id,因为库存只有10个。

然而,但是,在使用jmeter工具模拟多用户并发请求时,最后发现order:1中总是超过5个用户,也就是出现了“超抢/超卖”。

分析问题就出在这一段代码:

$len = \Redis::llen('order:1'); //检查库存,order:1 定义为健名
if($len >= $num)
    return '已经抢光了哦';

虽然llen和lpush2个操作如果单独执行是具备原子性的,然而上面这个业务2个命令组合起来才算是完成一个业务,但是2个命令组合起来就不具备原子性,所有在两个命令之间其他客户端会出现读写脏数据的情况。

在抢购进行到一定程度,假如现在已经有9个人抢购成功,又来了3个用户同时抢购,三个用户假设有先后顺序,但是在第一个用户lpush到redis之前,其他的两个用户其实已经获取push之前的长度9了,这时if条件将会被绕过(条件同时被满足了),这三个用户都能抢购成功。而实际上只剩下一件库存可以抢了。

在高并发下,很多看似不大可能是问题的,都成了实际产生的问题了。要解决“超抢/超卖”的问题,核心在于保证检查库存时的操作是依次执行的,再形象的说就是把“多线程”转成“单线程”。即使有很多用户同时到达,也是一个个检查并给与抢购资格,一旦库存抢尽,后面的用户就无法继续了。

我们需要使用redis的原子操作来实现这个“单线程”。首先我们把库存存在goods_store:1这个列表中,假设有10件库存,就往列表中push10个数,这个数没有实际意义,仅仅只是代表一件库存。抢购开始后,每到来一个用户,就从goods_store:1中pop一个数,表示用户抢购成功。当列表为空时,表示已经被抢光了。因为列表的pop操作是原子的,即使有很多用户同时到达,也是依次执行的。抢购的示例代码如下:

比如这里我先把库存(可用库存,这里我强调下哈,一般都是商品详情页抢购,后来者进来看到的库存可能不再是后台系统配置的10个库存数了)放入redis队列:

$num=10; //库存
$len=\Redis::llen('goods_store:1'); //检查库存,goods_store:1 定义为健名
$count = $num-$len; //实际库存-被抢购的库存 = 剩余可用库存
for($i=0;$i<$count;$i++)
    \Redis::lpush('goods_store:1',1);//往goods_store列表中,未抢购之前这里应该是默认滴push10个库存数了
//echo \Redis::llen('goods_store:1');//未抢购之前这里就是10了

好吧,抢购时间到了:

/* 模拟抢购操作,抢购前判断redis队列库存量 */
$count=\Redis::lpop('goods_store:1');//lpop是移除并返回列表的第一个元素。
if(!$count)
    return '已经抢光了哦';
/* 下面处理抢购成功流程 */
\DB::table('goods')->decrement('num', 1);//减少num库存字段

用户抢购成功后,上面的我们也可以稍微优化下,比如我们可用将用户ID存入了order:1列表中。接下来我们可以引导这些用户去完成订单的其他步骤,到这里才涉及到与数据库的交互。最终只有很少的人走到这一步吧,也就解决的数据库的压力问题。

我们再改下上面的代码:

$user_id = \Session::get('user_id');//当前抢购用户id
/* 模拟抢购操作,抢购前判断redis队列库存量 */
$count=\Redis::lpop('goods_store:1');
if(!$count)
    return '已经抢光了哦';
$result = \Redis::lpush('order:1',$user_id);
if($result)
    return '恭喜您!抢到了哦';

为了检测实际效果,我使用jmeter工具模拟100、200、1000个用户并发进行抢购,经过大量的测试,最终抢购成功的用户始终为10,没有出现“超抢/超卖”。

————————————————

版权声明:本文为CSDN博主「鱼满仓」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/luolaifa000/article/details/...



发表评论 请登录再评论
  •   文章分类
回到顶部