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

这篇具有很好参考价值的文章主要介绍了深入理解高并发超卖一系列问题与解决方案（近7万字详解，跳槽涨薪必备宝藏珍藏级分享）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

破除困境带你飞

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

一语道破

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

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

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

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

MySQL超卖原理分析

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

MySQL的解决方案

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

乐观锁：MySQL乐观锁与悲观锁
悲观锁：MySQL锁（读锁、共享锁、写锁、S锁、排它锁、独占锁、X锁、表锁、意向锁、自增锁、MDL锁、RL锁、GL锁、NKL锁、插入意向锁、间隙锁、页锁、悲观锁、乐观锁、隐式锁、显示锁、全局锁、死锁）
分布式锁：深入理解PHP+Redis实现分布式锁的相关问题

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脚本的过程不可被拆分，不可被中断，但是遇到错误不会回滚。

并发情况下MySQL与Redis缓存一致性问题详解

并发情况单个MySQL或单个Redis本身都有读写不一致的问题，更何况MySQL与Redis两个组件间通信又没有事务的约束，或者锁的加持，同样会出现一致性问题。
深入理解高并发下的MySQL与Redis缓存一致性问题（增删改查数据缓存的一致性、Canal、分布式系统CAP定理、BASE理论、强、弱一致性、顺序、线性、因果、最终一致性）