AI 助理
备案控制台
开发者社区 数据库 文章 正文

商品超买超卖问题分析及实战

2022-10-21 1512
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
Redis 开源版，标准版 2GB
推荐场景：
搭建游戏排行榜
云数据库 Tair（兼容Redis），内存型 2GB
推荐场景：
通过缓存加速数据库访问
性能测试 PTS，5000VUM额度
简介： 商品超买超卖问题分析及实战

项目场景：

商品超买超卖是高并发下非常典型的问题，也是面试中秒杀场景常常会问到的问题。

常见的问题有：

1、怎么设计一个秒杀系统？

2、商品超买、超卖问题产生的原因？

3、怎么防止商品出现超买｜超卖问题？

4、乐观锁和悲观锁的适用场景是什么？

5、提高事务的隔离级别能解决超买｜超卖问题吗？


今天和大家一起探究下商品超买、超卖的原因及其解决方案。


原因分析：

商品下单扣减库存的流程如下：

1、根据商品ID查询商品库存信息

2、判断商品库存是否大于购买数量

3、库存充足则进行下单减库存操作


模拟代码如下：

@Transactional(rollbackFor = Exception.class)
public void secKill(Integer goodsId, Integer num) throws InterruptedException {
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、使用减法计算出剩余库存
            int stockNum = goodsStock.getNum() - num;
            goodsStock.setNum(stockNum);
            //4、更新商品剩余库存的值
            int result = goodsStockMapper.updateByPrimaryKeySelective(goodsStock);
            if(result<0){
                 log.error("库存不足");
                 throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
            throw new RuntimeException("秒杀失败");
        }
    }


采用jMeter压测发现，这样的代码不但会出现超买超卖的问题，还会导致商品的剩余库存出现覆盖更新的情况。

流程分析：

1、在高并发的情况下，会有很多请求同时查询到商品的库存信息，进入到步骤1。

2、并通过了库存是否充足的判断，计算出剩余库存。

3、通过updateByPrimaryKeySelective方法直接将计算出的剩余库存的值写入到数据库。

假设A商品当前剩余库存是10，有10个线程同时进入到步骤1下单购买10个A商品，刚好都通过了步骤2的库存是否充足的判定，经过步骤3计算出剩余库存为0,然后执行更新操作将剩余库存的值写入到数据库。

最后我们发现，明明A商品只有10件，但是我们确卖出了100件。这就是商品的超买、超卖问题。


下面是模拟2个并发事务购买10个A商品的请求过程：

A商品库存只有10个，最后却卖出了20件。

57.png


原因说明：

1、添加事务控制并不能保证减库存方法secKill()执行的原子性，代码仍然会并发执行。

2、在并发场景下，先查询库存，再用java代码判定库存是否充足是不正确。

3、在并发场景下，如果先通过java代码计算出剩余库存，再把剩余库存的值更新到数据库中会导致出现覆盖更新的情况。


解决方案：

1、最简单暴力的办法，既然减库存的方法secKill()不支持并发，那么可以将整个方法块做异步处理。如果不考虑分布式，可以直接用synchronized关键字，如果需要支持分布式，可以采用redis加分布式锁。


2、采用悲观锁，给数据库记录加锁。


3、采用乐观锁，更新记录时通过比对版本号判定是否执行更新库存。


4、直接在sql中执行减法来更新库存,并在where调价中判定库存是否充足


update table set stock = stock - 10  where goods_id=1 and stock - 10 >=0 ;


代码实战：

1、商品库存表

CREATE TABLE `goods_stock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `goods_id` varchar(255) DEFAULT NULL COMMENT '商品id',
  `num` int(11) DEFAULT NULL COMMENT '库存数量',
  `version` int(11) unsigned DEFAULT NULL COMMENT '版本号',
  PRIMARY KEY (`id`),
  UNIQUE KEY `ui_goods_id` (`goods_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;
INSERT INTO `seckill`.`goods_stock`(`id`, `goods_id`, `num`, `version`) VALUES (1, '1', 10000, NULL);


2、控制层代码 SecKillController

@RestController
@Slf4j
public class SecKillController {
    @Autowired
    private SecKillService secKillService;
    @GetMapping(value = "/secKill/{goodsId}/{num}")
    public void secKill(@PathVariable Integer goodsId, @PathVariable Integer num) throws InterruptedException{
        secKillService.secKill(goodsId,num);
    }
}

1、synchronized方式

只需要在方法头上添加synchronized关键字，不用修改任何代码

@Transactional(rollbackFor = Exception.class)
    public synchronized void  secKill(Integer goodsId, Integer num) throws InterruptedException {
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            int stockNum = goodsStock.getNum() - num;
            goodsStock.setNum(stockNum);
            int result = goodsStockMapper.updateByPrimaryKeySelective(goodsStock);
            if(result < 1){
                 log.error("库存不足");
                 throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
            throw new RuntimeException("秒杀失败");
        }
    }


采用JMeter压测：

线程组：采用500个线程，请求20次。

56.png

http请求：采用get请求，http://localhost:8080/secKill/1/1，每次购买一个商品

55.png

执行日志：商品库存依次递减1，说明现在扣减库存的方法secKill()确实是异步执行。

54.png

优点：简单，只需要在方法头部加上一个synchronized关键字，不用修改其他代码。

缺点：不支持分布式，并发能力较弱。


2、redis分布式锁

 

public void  secKill(Integer goodsId, Integer num)  {
        RLock rlock = redissonClient.getLock("goods_sku");
        try{
             //加分布式锁
             rlock.lock();
             //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            int stockNum = goodsStock.getNum() - num;
            goodsStock.setNum(stockNum);
            int result = goodsStockMapper.updateByPrimaryKeySelective(goodsStock);
            if(result < 1){
                 log.error("库存不足");
                 throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
            throw new RuntimeException("秒杀失败");
        }
        }catch(Exception e){
            log.error("秒杀失败");
        }finally{
             rlock.unlock();
        }
    }


优点：支持分布式，能保证方法异步执行，避免超买超卖问题。

缺点：引入了redis中间件。


3、悲观锁

@Transactional(rollbackFor = Exception.class)
    public  void  secKill(Integer goodsId, Integer num) throws InterruptedException {
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStockForUpdate(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            int result = goodsStockMapper.secKill(goodsId,num);
            if(result < 1){
                 log.error("库存不足");
                 throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
            throw new RuntimeException("秒杀失败");
        }
    }


<select id="getStockForUpdate" resultType="com.laowan.seckill.modle.GoodsStock">
    select
    <include refid="Base_Column_List" />
    from goods_stock
    where goods_id = #{goodsId} for update
  </select>
  <select id="getStock" resultType="com.laowan.seckill.modle.GoodsStock">
    select
    <include refid="Base_Column_List" />
    from goods_stock
    where goods_id = #{goodsId}
  </select>
 <update id="secKill">
    update goods_stock
    set  num = num - #{num}
    where goods_id = #{goodsId}
  </update>


核心是在执行goodsStockMapper.getStockForUpdate(goodsId)方法时，通过在查询语句后面添加for update，会去尝试给查询的记录添加写锁（排他锁）。

这样当第一个事务A进来获取写锁后，后面的事务就不能获取该记录上的写锁，会一直等待事务A执行完毕释放写锁后，再竞争获取写锁，才能执行扣减库存的操作。


select * from goods_stock where goods_id = #{goodsId} for update


优点：支持分布式，充分利用了数据库的排他锁机制，保证扣减库存的操作串行执行。

缺点：并发效率相比synchronized、redis分布式锁会低很多，并且容易导致mysql死锁的问题。


悲观锁方式本质上是利用数据库的排他锁的特性，让事务内代码异步串行执行，从而避免了超买超卖问题。


上面介绍的几种方式，本质上都是通过加锁的方式，使得扣减库存的操作异步串行执行。

那么有没有不用加锁的方式呢？


4、乐观锁

@Transactional(rollbackFor = Exception.class)
    public  void  secKill(Integer goodsId, Integer num) throws InterruptedException {
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            goodsStock.setNum(num);
            int result = goodsStockMapper.secKillForVersion(goodsStock);
            if(result < 1){
                 log.error("库存不足");
                 throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
            throw new RuntimeException("秒杀失败");
        }
    }
<update id="secKillForVersion">
    update goods_stock
       set  num = num - #{num},version=version+1
    where goods_id = #{goodsId} and version=#{version}
</update>

验证：

数据准备：


INSERT INTO `seckill`.`goods_stock`(`id`, `goods_id`, `num`, `version`) VALUES (1, '1', 1000, 0);


53.png


JMeter压测：

51.png

执行结果：

52.png

乐观锁的版本号增长了779，商品的库存也正好扣减了779，说明成功控制了扣减库存的并发。

通过增加了版本号的控制，在扣减库存的时候在where条件进行版本号的比对。

实现查询的是哪一条记录，那么就要求更新的是哪一条记录，在查询到更新的过程中版本号不能变动，否则更新失败。


改进：

增加乐观锁的循环次数，提高请求成功的概率。

public  void  secKill(Integer goodsId, Integer num) throws InterruptedException {
           int retryCount = 0;
           int result = 0;
            //1、查询商品库存
            GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
            //2、判断库存是否充足
            if(goodsStock.getNum() < num){
                log.error("库存不足");
                throw new RuntimeException("秒杀失败");
            }
            //最多重试3次
            while(retryCount < 3 && result == 0){
                result = this.reduceStock(goodsId,num);
                retryCount++;
            }
            if(result > 0){
                log.info("秒杀成功");
            }else{
                log.error("库存不足");
                throw new RuntimeException("秒杀失败");
            }
    }
    /**
     * 减库存
     * 
     * 由于默认的事务隔离级别是可重复读，会导致在同一个事务中查询3次goodsStockMapper.getStock()
     * 得到的数据始终是相同的，所以需要提取reduceStock方法。每次循环都启动新的事务尝试扣减库存操作。
     */
    @Transactional(rollbackFor = Exception.class)
    public  int  reduceStock(Integer goodsId, Integer num){
        int result = 0;
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            goodsStock.setNum(num);
            result = goodsStockMapper.secKillForVersion(goodsStock);
        }
        return result;
    }


注意⚠️：

不能在同一个事务里面，重试扣减库存的操作。


最后压测发现，扣减库存请求的成功率提高了很多。但请求过程中还是会出现大量版本冲突的问题。


乐观锁机制类似java中的cas机制，在查询数据的时候不加锁，只有更新数据的时候才比对数据是否已经发生过改变，没有改变则执行更新操作，已经改变了则进行重试。


乐观锁机制在大并发场景下，会出现大量的版本冲突导致重试的情况，而这种重试无疑会增大数据库和程序的压力。 显然乐观锁方式并不适合高并发的场景。


5、where条件

where条件的方式主要是将库存是否充足的判定放在了更新库存的where条件中，以此保证不会出现超买超卖的情况。

@Transactional(rollbackFor = Exception.class)
    public  void  secKill(Integer goodsId, Integer num) throws InterruptedException {
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            int result = goodsStockMapper.secKillForWhere(goodsId,num);
            if(result < 1){
                log.error("库存不足");
                throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
            throw new RuntimeException("秒杀失败");
        }
    }


在更新语句中扣减库存，并在where调价中判定库存是否充足。


<update id="secKillForWhere">
    update goods_stock
        set  num = num - #{num}
    where goods_id = #{goodsId} and num - #{num} >=0
  </update>


JMeter压测：


INSERT INTO `seckill`.`goods_stock`(`id`, `goods_id`, `num`, `version`) VALUES (1, '1', 500, 0);


50.png


线程数设置：

也可以加大线程数，看是否会出现库存数被扣减成负数的情况。

48.png


压测结果：

库存成功被扣完，且没有出现异常，执行效率也非常高。

49.png


6、unsigned 非负字段限制

本质上来说，这种方式和where条件方式类似。

where条件是通过限制扣减库存的查询条件来限制超卖

unsigned 非负字段限制是如果扣减库存出现负值后，在保存的时候会报错来防止出现超卖。


库存字段num增加非负字段限制unsigned，保证只能保存非负整数。

CREATE TABLE `goods_stock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `goods_id` varchar(255) DEFAULT NULL COMMENT '商品id',
  `num` int(11) unsigned DEFAULT NULL COMMENT '库存数量',
  `version` int(11) unsigned DEFAULT NULL COMMENT '版本号',
  PRIMARY KEY (`id`),
  UNIQUE KEY `ui_goods_id` (`goods_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;


@Transactional(rollbackFor = Exception.class)
public  void  secKill(Integer goodsId, Integer num) throws InterruptedException {
        //1、查询商品库存
        GoodsStock  goodsStock  = goodsStockMapper.getStock(goodsId);
        //2、判断库存是否充足
        if(goodsStock.getNum() >= num){
            //3、减库存
            int result = goodsStockMapper.secKill(goodsId,num);
            if(result < 1){
                log.error("库存不足");
                throw new RuntimeException("秒杀失败");
            }else{
                log.info("秒杀成功");
            }
        }else{
            log.error("库存不足");
        }
    }


压测过程中出现如下异常提示:


Data truncation: BIGINT UNSIGNED value is out of range in '(`seckill`.`goods_stock`.`num` - 1)'


说明库存不足时，不能继续扣减库存。


小结：

unsigned 非负字段限制方式算是一种兜底策略，从底层数据库底层数据规则的层面限制出现超买超卖的情况。 并且简单有效，能和其他方式共同使用，防止超卖超卖情况的出现。


为什么不通过事务隔离级别控制事务代码的并发

简单来说，事务的隔离级别并不能控制事务代码的并发。


事务是什么？

Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.


事务是由一组SQL语句组成的原子操作单元，其对数据的变更，要么全都执行成功(Committed)，要么全都不执行(Rollback)。

47.png

InnoDB实现的数据库事务具有常说的ACID属性，即原子性(atomicity)，一致性(consistency)、隔离性(isolation)和持久性(durability)。


原子性：事务被视为不可分割的最小单元，所有操作要么全部执行成功，要么失败回滚(即还原到事务开始前的状态，就像这个事务从来没有执行过一样)

一致性：在成功提交或失败回滚之后以及正在进行的事务期间，数据库始终保持一致的状态。如果正在多个表之间更新相关数据，那么查询将看到所有旧值或所有新值，而不会一部分是新值，一部分是旧值

隔离性：事务处理过程中的中间状态应该对外部不可见，换句话说，事务在进行过程中是隔离的，事务之间不能互相干扰，不能访问到彼此未提交的数据。这种隔离可通过锁机制实现。有经验的用户可以根据实际的业务场景，通过调整事务隔离级别，以提高并发能力

持久性：一旦事务提交，其所做的修改将会永远保存到数据库中。即使系统发生故障，事务执行的结果也不能丢失。

这里我们要注意：

事务的原子性指的是在事务范围内执行的insert、update、delete要么全部成功，要么全部失败。而并不能保证添加了@Transactional注解声明事务的方法的执行具有原子性，也不能保证在事务A执行一系列insert、update、delete操作的过程中，事务B不能执行insert、update、delete操作。


场景一：

在默认的事务隔离级别下，可重复读（Repeatable Read）由于采用了MVCC机制，读不加锁，所以都可以查询到商品的库存信息，进行扣减库存的操作，这里都可以并发执行。

直到运行到update的操作，由于需要先获取到数据的排他锁，才能执行更新操作，才变为串行执行。

所以，这里如果采用在事务代码中，用java代码的方式先求出剩余库存，再将值更新到数据库，就会出现覆盖更新的情况。

46.png


场景二： 串行化（Serializable）

如果我们将事务的隔离级别提升为串行化（Serializable），执行的情况呢？

45.png

可以发现，尽管将事务的隔离级别提升为串行化（Serializable），也只是影响了在事务中执行sql时的加锁方式，并不能保证事务范围内的代码异步执行。

小结：

事务隔离级别串行化（Serializable）并不能保证事务访问内的逻辑在并发场景下的串行化执行，大家不要被其命名所误导。

串行化（Serializable）隔离级别只能保证，先查到的，先更新。


总结：

本文主要对商品超买超卖问题进行了深度分析，并提供了相关解决方案和实战代码，通过JMeter压测对其正确性进行了验证。

1、介绍了高并发场景下商品超买超卖问题出现的原因。

2、通过代码实战介绍了6种方式解决超买超买问题：


synchronized方式

redis分布式锁

悲观锁

乐观锁

where条件

unsigned 非负限制


其中前3种是通过加锁的方式保证扣减库存代码串行执行，后面3种是无锁方式。


3、如果事务代码中涉及到复杂计算，需要先通过java代码计算，然后再将计算结果更新到数据库，这种情况推荐采用synchronized方式、redis分布式锁、悲观锁这些加锁的方式，保证整个事务范围内的代码串行执行，防止出现覆盖更新的情况。

如果是像扣减库存这样简单的计算操作，可以在update中轻松实现的情况，推荐采用where条件、unsigned 非负限制方式，并发的效率更高。


4、强烈建议unsigned 非负限制方式能和其他方式一起使用，保证数据安全性。

5、乐观锁为什么不适合在高并发场景下使用

6、介绍了为什么不能通过提高事务的隔离级别来解决超买超卖的问题.

文章标签：
云数据库 Tair（兼容 Redis）
性能测试
Java
测试技术
SQL
关系型数据库
NoSQL
MySQL
Redis
中间件
数据库
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务，基于高可靠双机热备架构及可无缝扩展的集群架构，满足高读写性能场景及容量需弹性变配的业务需求。 产品详情：https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验：数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引，您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接，领取免费ECS&amp;RDS资源，30分钟完成数据库上云实战！https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
星繁
目录
相关文章
爱专研的技术土狗
|
21天前
分享一些在 1688 上找一件代发商品的技巧
在1688上找一件代发商品需明确自身需求与定位，筛选可靠供应商，研究商品信息，利用精准搜索和平台推荐，关注活动，并与供应商充分沟通，确保合作顺畅。
爱专研的技术土狗
61 0
一百减一是零
|
6月前
|
消息中间件 供应链 NoSQL
电商订单待支付(思路分析)
电商订单待支付(思路分析)
一百减一是零
162 0
编程千纸鹤
|
6月前
|
算法 前端开发 Java
基于Java实现超市积分系统
基于Java实现超市积分系统
编程千纸鹤
126 0
greework
|
算法 Python
算法创作|模拟商品加入购物车并结算价钱问题解决方法
算法创作|模拟商品加入购物车并结算价钱问题解决方法
greework
107 0
算法创作|模拟商品加入购物车并结算价钱问题解决方法
winx_19970108018
|
XML JSON 缓存
Java实现商品ID获取淘宝商品快递费用数据方法
Java实现商品ID获取淘宝商品快递费用数据方法
winx_19970108018
213 0
电商API开发15870092527
|
数据挖掘 API
淘宝商品数据分析怎么操作？从哪些方面下手？
淘宝商品数据分析怎么操作？从哪些方面下手？
电商API开发15870092527
216 0
技术小达人
阿云漫画 | 淘宝“2021年度十大商品”，你get过几件？
编者按： 2021年还有29小时30分钟就要结束了，该用什么记录这一年?继各大平台陆续发布年度关键词、热搜、弹幕之后，国民电商平台淘宝也发布了一份特殊的年度榜单。网友看完表示，“这一年的人间烟火味都在这了。”
技术小达人
190 0
探索云世界
|
6月前
|
存储 移动开发 算法
一文理解淘宝购物车背后的逻辑
提升用户的使用体验才是产品升级的核心，本文将从业务发展以及技术沉淀两个方面来总结淘宝购物车的产品升级之路。
探索云世界
798 0
一文理解淘宝购物车背后的逻辑
ik1003
LeetCode每日一题——1475. 商品折扣后的最终价格
给你一个数组 prices ，其中 prices[i] 是商店里第 i 件商品的价格。
ik1003
111 0
i54lsakkiu43e
|
监控 BI
一文看懂：商品分析如何做？
今天分享的是商品分析。在过去，商品分析曾经是最重要的分析内容，但现在已经让位给推广分析了，一起来看下吧。
i54lsakkiu43e
388 0
一文看懂：商品分析如何做？

热门文章

最新文章

  • 1
    尝鲜：如何搭建一个简单的webrtc服务器
  • 2
    从零开始：阿里云上Kubernetes集群的搭建与部署
  • 3
    面试必问的4种单点登录的实现方式，你知道几个？
  • 4
    Github Pages+Hexo+阿里云域名绑定
  • 5
    测试开启MySQL performance_schema后对性能的影响
  • 6
    阿里云视频云总经理何亚明：基于倚天的视频云原生业务新范式
  • 7
    Windows SDK编程(Delphi版) 之 消息框和菜单资源
  • 8
    三级侧边栏-树形菜单案例效果
  • 9
    U盘故障详细维修方法
  • 10
    1、Windows API函数归总，网络函数、消息函数、文件处理
  • 1
    如何在项目中保证 Web 组件化的性能
    15
  • 2
    如何在项目中高效地进行 Web 组件化开发
    14
  • 3
    Vue3中v-model在处理自定义组件双向数据绑定时，如何避免循环引用？
    15
  • 4
    Vue3中v-model在处理自定义组件双向数据绑定时有哪些注意事项？
    102
  • 5
    在 Vue 3 中，如何使用 v-model 来处理自定义组件的双向数据绑定？
    20
  • 6
    网络漏洞
    16
  • 7
    网络安全
    14
  • 8
    完整性
    14
  • 9
    可用性
    97
  • 10
    可靠性
    13

    • 相关课程

    更多
  • 实时数据应用：实现淘宝母婴订单实时查询和可视化
  • 天池新人实战赛o2o优惠券使用预测代码学习分享

    • 相关电子书

    更多
  • 外卖广告架构实践
  • 电商平台优化纪实
  • 《淘宝推荐业务介绍》

    • 相关实验场景

    更多
  • 基于Redis实现在线游戏积分排行榜
  • 实现淘宝母婴订单实时查询和实时大屏
  • 收银台的场景化界面实践
  • 使用EDA架构部署在线外卖订单系统
  • 小试牛刀，一键部署电商商城
    • 下一篇
    无影云桌面