深入理解高并发超卖一系列问题与解决方案（近7万字详解，跳槽涨薪必备宝藏珍藏级分享）

最新推荐文章于 2024-05-15 03:50:26 发布

小松聊PHP进阶

最新推荐文章于 2024-05-15 03:50:26 发布

阅读量952

点赞数 16

分类专栏： MySQL Redis PHP 文章标签： java php mysql sql redis 搜索引擎后端

本文链接：https://blog.csdn.net/weixin_42100387/article/details/137576372

版权

PHP 同时被 3 个专栏收录

59 篇文章 3 订阅

订阅专栏

MySQL

19 篇文章 2 订阅

订阅专栏

Redis

9 篇文章 1 订阅

订阅专栏

文章探讨了在高并发场景中，MySQL和Redis如何面临超卖问题，以及如何通过乐观锁、悲观锁和分布式锁解决并发安全问题。同时，强调了并发带来的数据一致性、幂等性和查询优化的重要性。

摘要由CSDN通过智能技术生成

破除困境带你飞

能遇上高并发的，基本都是有点规模的公司，小公司基本都是CRUD。
想去一线城市跳槽，想去有高并发的公司，但是没有高并发经验，没有高并发的经验，就去不了高并发的公司，去不了这样的公司，就没有高并发经验，前狼后虎两头堵的困境，干就完了。

一语道破

超卖问题是属于并发安全问题，在并发情况下出现数据一致性的问题的表现，据有代表性。
这是个概率问题，不是一定发生或一定不发生。
核心问题就两个：

并发引起的资源竞争却没有加锁，导致运行时序不可控（MySQL超卖）。
多个读写操作存在间隙，导致并发请求通过间隙插队引发的时序不可控问题（Redis超卖）。

解决方案也很简单，上锁或者保证无间隙执行就行了。

并发问题仅仅只是一种，至于并发带来的，大数据存储、检索、以及安全问题都是需要考虑进去的。

MySQL超卖原理分析

假设无并发情况下代码逻辑没问题。这个问题主要出现在获取库存数据的方式上，并发过来时，多个请求获取到的库存一致，然后都在这个一致的库存基础上扣库存，自然要出错。

MySQL的解决方案

并发存在资源争夺问题，时序是不可控的，所以要上锁，强制在短时间内让数据串行更改。

Redis超卖原理分析

Redis超卖，主要是开发者没有考虑到并发下资源争夺的间隙问题。
redis get(‘stock’)是5，然后decr(‘stock’)，想让库存减到4，看起来没毛病。
但是get和decr是两条语句，因此存在间隙，get(‘stock’)是5只能代表执行的那个时刻是5，decr在执行时不能保证redis是以5的基础上自减的，可能已经被秒成0了。

Redis的解决方案

笨方法：
由于Redis是单线程的，利用Redis双向链表的特性可以完成，利用左推右拉的单向队列完成对库存的扣减。笨方法，笨就笨在要是有1000个商品，一共50000个库存，难道要存50000条数据吗。

伪代码如下：
实现通过缓存预热，将商品id缓存进redis队列中，例如：lPush('goods_ids' , 商品id)	
然后抢购时：在逐个取出来，利用这些数据，做其它逻辑操作rPush('goods_ids', 商品id)，知道这个动作返回false，证明库存全部扣完。

Redis+lua：
利用Redis+Lua脚本的方式，让扣库存的动作无间隙执行，超卖问题，用redis操作string，或者hash类型都行。

//用字符串类型操作，单商品库存
$lua = <<<EOF
    local stock_key   = KEYS[1]                                -- Redis中存储库存数量的键名
    local input_stock = tonumber(ARGV[1])                      -- 要扣除的库存数量
    local redis_stock = tonumber(redis.call('GET', stock_key)) -- 获取当前库存数量
    if redis_stock >= input_stock then
        redis.call('DECRBY', stock_key, input_stock)           -- 如果库存充足，则扣除库存数量
        return redis_stock - input_stock                       -- 返回扣除后的库存数量
    else
        return -1                                              -- 库存不足，返回标记值，别返回0，有歧义
    end
EOF;

$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
//stock为string名，2为要扣库存的数量
$res = $redis->eval($lua, ['stock' , 2], 1);
if($res == -1) {
    //库存不足
}

//库存充足，其它下游流程...

用hash类型操作多商品库存

$script = <<<EOF
    local hash_key    = KEYS[1]
    local goods_id    = KEYS[2]
    local input_stock = - tonumber(ARGV[1])
    if input_stock >= 0 then
        return -1 -- 表单验证
    end
    
    local redis_stock = tonumber(redis.call('HGET', hash_key, goods_id))
    if redis_stock == nil then
        return -2 -- 商品不存在
    end

    local stock_res = redis_stock + input_stock
    if stock_res < 0 then
        return -3 -- 库存不足
    end

    redis.call('HSET', hash_key, goods_id, stock_res)
    return stock_res
EOF;
//扣减商品id为50的3个库存。
$res = $redis->eval($script, ['stock', 50, 3], 2);
if($res == -1) {
    echo '库存数据不合法';
    return;
}
if($res == -2) {
    echo '商品不存在';
    return;
}
if($res == -3) {
    echo '库存不足';
    return;
}

echo "库存扣减成功，当前库存为：{$res}";

关于Redis+Lua是否是原子性执行的争议问题

https://redis.io/docs/latest/develop/interact/programmability/eval-intro/
对Redis官网进行搜索，出现了原子性的字眼。
原话是：
Blocking semantics that ensure the script’s atomic execution.
Lua lets you run part of your application logic inside Redis. Such scripts can perform conditional updates across multiple keys, possibly combining several different data types atomically.

但是我想了想有矛盾的地方：
MySQL使用了undo log来保证原子性，要么成功全部执行，要么失败全部回滚。
众所周知，Redis不支持回滚的，那么ACID的A就没办法全部保证，最多是没有执行期间没有间隙，不被其它过来的请求影响，引起并发问题。

然后我又看了看阿里某架构师对此的剖析，跟我设想的一样：
Redis会把Lua脚本当做一个整体去执行，中间不会被其它的命令插入，但是如果执行过程中出现了错误，事务是不会回滚的。
也就意味着执行Lua脚本的过程不可被拆分，不可被中断，但是遇到错误不会回滚。