通用互斥锁和逻辑过期方案解决redis缓存击穿

已于 2023-10-13 21:15:36 修改
阅读量535 收藏
点赞数 1
文章标签： 缓存 redis 数据库
于 2023-10-12 15:57:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_63612259/article/details/133792804
版权

通用互斥锁和逻辑过期方案解决redis缓存击穿

image-20231011151405868

缓存击穿

有时候，我们在访问热点数据时。比如：我们在某个商城购买某个热门商品。

为了保证访问速度，通常情况下，商城系统会把商品信息放到缓存中。但如果某个时刻，该商品到了过期时间失效了。

此时，如果有大量的用户请求同一个商品，但该商品在缓存中失效了，一下子这些用户请求都直接打到数据库，可能会造成瞬间数据库压力过大，而直接挂掉。

这种情况通常有下面几种解决方案：

  • 如果业务允许，将key值设置为永不过期。
  • 使用互斥锁，保证在缓存失效仅有一个线程访问数据库，降低了在同一时刻打在数据库上的请求，防止数据库打死。当然加锁会导致系统的性能变差，但能在一定程度上保证用户访问的数据不为过期的旧数据。
  • 使用逻辑过期
    • 在将数据缓存到redis中添加一个逻辑过期时间，并将缓存的key值设置为永不过期。
    • 拿到缓存时获取到逻辑过期时间比较当前时间
      • 过期：获取互斥锁
        • 成功：返回缓存数据并开启一个异步线程更新缓存数据，更新完成后释放锁。
        • 失败：说明已经有其它请求开启异步线程更新缓存，直接返回缓存数据。
      • 未过期：返回缓存数据

方案一：互斥锁方案

代码逻辑

  • 从数据库拿到缓存数据
    • 命中直接返回数据，若缓存是""则返回null解决缓存击穿。
  • 尝试获取锁并重建缓存
    • 获取互斥锁成功
      • 从数据库中获取数据，并重建缓存。(若数据库同样不存在该数据则缓存控制解决缓存击穿)。
    • 获取互斥锁失败
      • 递归调用方法，直到缓存重建成功

方法签名

因为需要考虑到通用性，我们需要使用Java泛型来设计方法，我们用泛型R来表示缓存的类型。方法的签名如下：

public <R> R queryWithMutex(String key,Class<R> type, Supplier<R> dbSupplier, Long time, TimeUnit unit)
  • R：表示缓存的类型
  • key：获取缓存需要缓存的key
  • type ：返回值类型(class)
  • dbSupplier：存储数据库中的数据(函数式接口)
  • time:缓存有效期
  • unit：缓存有效期时间单位

代码

/**
 * 互斥锁解决缓存击穿
 * @param key 缓存的key
 * @param type 返回值类型(class)
 * @param dbSupplier 获取数据库的数据
 * @param time 过期时间
 * @param unit 时间单位
 * @param <R> 返回数据类型
 * @return
 */
public <R> R queryWithMutex(String key,Class<R> type, Supplier<R> dbSupplier, Long time, TimeUnit unit){

    String CacheStr = getCache(key);
    // 缓存为空说明数据库和缓存中都不存在该数据(缓存穿透)
    if("".equals(CacheStr)){
        log.info("缓存穿透~~~");
        return null;
    }
    //缓存命中直接将数据返回
    if(CacheStr != null) {
        log.info("走了缓存~~~");
        return JSONUtil.toBean(CacheStr,type);
    }
    //互斥锁重建缓存
    R dbData = null;
    SimpleRedisLock simpleRedisLock = new SimpleRedisLock(stringRedisTemplate,key.substring(key.indexOf(":")));
    try {
        //已经有线程开始重构，其余线程等待
        if(!simpleRedisLock.tryLock(20l)){
            log.info("我没拿到锁，我需要等。。。" + Thread.currentThread().getId());
            Thread.sleep(500);
            return queryWithMutex(key,type,dbSupplier,time,unit);
        }
        log.info("我拿到锁，进行缓存重建,{},{}",key,Thread.currentThread().getId());
        dbData = dbSupplier.get();
        Thread.sleep(15000);
        //缓存穿透
        if(dbData == null){
            set(key, "",CACHE_NULL_TTL,TimeUnit.MINUTES );
            return null;
        }
        set(key,dbData,time,unit);
    }catch (Exception e){
        throw new RuntimeException(e);
    }finally {
        simpleRedisLock.unlock();
    }
    return dbData;
}

调用方法

该方法作用是根据id返回对应的文章详情。

@Override
    public Result detailArticle(Long id,Boolean isEdit) {
        ArticleVo articleVo = cacheClient.queryWithMutex(
                RedisConstants.CACHE_Article_KEY + id,
                ArticleVo.class,
                () -> ArticleToArticleVo(lambdaQuery().eq(Article::getId, id).one(), true),
                RedisConstants.CACHE_Article_TTL,
                TimeUnit.MINUTES
        );
        if(articleVo == null) return Result.fail(ARTICLE_NOT_EXIST.getCode(),ARTICLE_NOT_EXIST.getMsg());
        return Result.success(articleVo);
    }

其中需要注意的点就是Supplier<R> dbSupplier参数需要传入一个() -> x的lambda表达式或者方法引用，其中返回的x即为需要进行缓存的数据，并且需要将操作数据库的操作放入lambda表达式中。

测试

我们在重建缓存时使线程sleep了15s来模拟缓存重建，并记录相关日志以测试互斥锁是否生效。我们使用postman发送两个请求获取文章id为1的数据：

控制台：

2023-10-11T15:00:48.402+08:00  INFO 17040 --- [nio-8888-exec-2] com.duan.blog.utils.CacheClient          : 我拿到锁，进行缓存重建,cache:article:1,35


JDBC Connection [HikariProxyConnection@1604163156 wrapping com.mysql.cj.jdbc.ConnectionImpl@66995400] will not be managed by Spring
==>  Preparing: SELECT id,title,summary,comment_counts,view_counts,author_id,body_id,category_id,weight,create_date FROM tb_article WHERE (id = ?)
==> Parameters: 1(Long)
<==    Columns: id, title, summary, comment_counts, view_counts, author_id, body_id, category_id, weight, create_date
.......
对数据库的操作

可以看到线程id为35的线程获取到了锁并进行了缓存重建。

2023-10-11T15:00:48.970+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 我没拿到锁，我需要等。。。38
2023-10-11T15:00:49.487+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 我没拿到锁，我需要等。。。38
2023-10-11T15:00:49.998+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 我没拿到锁，我需要等。。。38
2023-10-11T15:00:50.519+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 我没拿到锁，我需要等。。。38
2023-10-11T15:00:51.037+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 我没拿到锁，我需要等。。。38
2023-10-11T15:00:51.551+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 我没拿到锁，我需要等。。。38
.........
重复

可以看到第二个线程id为38的未获取到锁而进行等待

2023-10-11T15:01:03.863+08:00  INFO 17040 --- [nio-8888-exec-5] com.duan.blog.utils.CacheClient          : 走了缓存~~~
2023-10-11T15:01:37.334+08:00  INFO 17040 --- [nio-8888-exec-3] com.duan.blog.utils.CacheClient          : 走了缓存~~~
2023-10-11T15:01:56.831+08:00  INFO 17040 --- [nio-8888-exec-6] com.duan.blog.utils.CacheClient          : 走了缓存~~~
2023-10-11T15:01:59.639+08:00  INFO 17040 --- [nio-8888-exec-7] com.duan.blog.utils.CacheClient          : 走了缓存~~~

线程id35重建缓存成功之后另一个等待的线程就获取到了缓存中的数据而未去访问数据库，并且在后续访问中都从缓存中拿到了数据。因此测试后发现该互斥锁方案生效，是一种解决缓存击穿的方案。

方案二：逻辑过期

代码逻辑

  • 提前对需要缓存的数据进行预热，存入逻辑过期时间。
  • 根据key拿到缓存后判断逻辑过期时间是否过期
    • 过期则获取互斥锁
      • 成功：开启异步线程更新缓存，并将过期数据返回
      • 失败：直接返回过期数据
    • 未过期则返回缓存数据

方法签名

public <R> R queryWithLogicalExpire(String key,Class<R> type, Supplier<R> dbSupplier, 
                                    Long expire, TimeUnit unit)
  • R：表示缓存的类型
  • key：获取缓存需要缓存的key
  • type ：返回值类型(class)
  • dbSupplier：存储数据库中的数据(函数式接口)
  • time:缓存有效期
  • unit：缓存有效期时间单位

代码

缓存预热：

@Test
    public void preCache(){
        cacheClient.setWithLogicalExpire(
                RedisConstants.CACHE_Article_KEY + 1,
                articleService.lambdaQuery().eq(Article::getId, 1).one(),
                30l,
                TimeUnit.SECONDS);
    }

/**
     * 逻辑过期方案解决缓存击穿
     * @param key 缓存的key
     * @param type 返回值类型(class)
     * @param dbSupplier 获取数据库的数据
     * @param expire 过期时间
     * @param unit 时间单位
     * @param <R> 返回数据类型
     * @return
     */
    @Resource
    ThreadService threadService;

    public <R> R queryWithLogicalExpire(String key,Class<R> type, Supplier<R> dbSupplier, Long expire, TimeUnit unit){

        RedisData redisData = getCache(key,RedisData.class);
        //判断数据是否过期
        R cache = BeanUtil.toBean(redisData.getData(), type);
        if(redisData.getExpireTime().isAfter(LocalDateTime.now())) return cache;
        log.info("缓存过期");
        SimpleRedisLock simpleRedisLock = new SimpleRedisLock(stringRedisTemplate,key.substring(key.indexOf(":")));
        log.info("我拿到锁，开始异步线程重构缓存");
        if(simpleRedisLock.tryLock(10l)){
            try {
                threadService.rebuildCache(
                        new RedisData(LocalDateTime.now().plusSeconds(unit.toSeconds(expire)),dbSupplier.get()),
                        key,stringRedisTemplate);
            }catch (Exception e){
                throw new RuntimeException();
            }finally {
                simpleRedisLock.unlock();
            }
        }
        return cache;
    }

@Override
public <R> void rebuildCache(R dbData,String cacheKey, StringRedisTemplate stringRedisTemplate) {
    stringRedisTemplate.opsForValue().set(cacheKey, JSONUtil.toJsonStr(dbData));
    log.info("重建缓存成功。。。。"+Thread.currentThread().getId());
}

其中rebuildCache方法是由异步线程池来执行的。

调用方法

该方法作用是根据id返回对应的文章详情。

@Override
    public Result detailArticle(Long id,Boolean isEdit) {
        Article articleVo = cacheClient.queryWithLogicalExpire(
                RedisConstants.CACHE_Article_KEY + id,
                Article.class,
                () -> lambdaQuery().eq(Article::getId, id).one(),
                RedisConstants.CACHE_Article_TTL,
                TimeUnit.MINUTES
        );
        if(articleVo == null) return Result.fail(ARTICLE_NOT_EXIST.getCode(),ARTICLE_NOT_EXIST.getMsg());
        return Result.success(articleVo);
    }

其中需要注意的点就是Supplier<R> dbSupplier参数需要传入一个() -> x的lambda表达式或者方法引用，其中返回的x即为需要进行缓存的数据，并且需要将操作数据库的操作放入lambda表达式中。

测试

  1. 先测试缓存未过期的情况:
Result(success=true, code=200, msg=success, data=Article(id=1, title=springboot介绍以及入门案例, summary=通过Spring Boot实现的服务，只需要依靠一个Java类，把它打包成jar，并通过`java -jar`命令就可以运行起来。

这一切相较于传统Spring应用来说，已经变得非常的轻便、简单。, commentCounts=1, viewCounts=178, authorId=1, bodyId=1, categoryId=2, weight=0, createDate=1695280032000))

可以看到请求并未访问数据库而是从缓存拿到数据。

  1. 缓存过期的情况：
2023-10-12T15:43:31.334+08:00  INFO 13792 --- [           main] com.duan.blog.utils.CacheClient          : 缓存过期
2023-10-12T15:43:31.338+08:00  INFO 13792 --- [           main] com.duan.blog.utils.CacheClient          : 我拿到锁，开始异步线程重构缓存
Creating a new SqlSession
SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@41736818] was not registered for synchronization because synchronization is not active
2023-10-12T15:43:31.387+08:00  WARN 13792 --- [           main] c.b.m.c.t.support.ReflectLambdaMeta      : Unable to make field private final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass accessible: module java.base does not "opens java.lang.invoke" to unnamed module @6cd8737
2023-10-12T15:43:31.399+08:00  INFO 13792 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
2023-10-12T15:43:31.529+08:00  INFO 13792 --- [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Added connection com.mysql.cj.jdbc.ConnectionImpl@5fa3df
2023-10-12T15:43:31.530+08:00  INFO 13792 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
JDBC Connection [HikariProxyConnection@2061363062 wrapping com.mysql.cj.jdbc.ConnectionImpl@5fa3df] will not be managed by Spring
==>  Preparing: SELECT id,title,summary,comment_counts,view_counts,author_id,body_id,category_id,weight,create_date FROM tb_article WHERE (id = ?)
==> Parameters: 1(Long)
.....数据库操作

2023-10-12T15:43:31.603+08:00  INFO 13792 --- [           main] c.d.blog.Service.impl.ThreadServiceImpl  : 重建缓存成功。。。。1

可以看到缓存过期后我们成功重建了缓存并刷新了逻辑过期时间。

下面使用postman同时发送两个情况测试缓存过期的情况，并手动更改数据库数据与缓存数据不一致：

请求一获取的数据：

{
    "success": true,
    "code": 200,
    "msg": "success",
    "data": {
        "id": "1",
        "title": "springboot介绍以及入门案例",
        "summary": "通过Spring Boot实现的服务，只需要依靠一个Java类，把它打包成jar，并通过`java -jar`命令就可以运行起来。\r\n\r\n这一切相较于传统Spring应用来说，已经变得非常的轻便、简单。",
        "commentCounts": 1,
        "viewCounts": 178, //缓存不一致
        "authorId": "1",
        "bodyId": "1",
        "categoryId": "2",
        "weight": 0,
        "createDate": "1695280032000"
    }
}

请求二获取的数据：

{
    "success": true,
    "code": 200,
    "msg": "success",
    "data": {
        "id": "1",
        "title": "springboot介绍以及入门案例",
        "summary": "通过Spring Boot实现的服务，只需要依靠一个Java类，把它打包成jar，并通过`java -jar`命令就可以运行起来。\r\n\r\n这一切相较于传统Spring应用来说，已经变得非常的轻便、简单。",
        "commentCounts": 1,
        "viewCounts": 180, 与数据库相同
        "authorId": "1",
        "bodyId": "1",
        "categoryId": "2",
        "weight": 0,
        "createDate": "1695280032000"
    }
}

从这我们可以看出，缓存过期与缓存重建成功之间的请求获取到的数据是与数据库不一致的。

总结

**互斥锁方案:**由于保证了互斥性，所以数据一致，且实现简单，因为仅仅只需要加一把锁而已，也没其他的事情需要操心，所以没有额外的内存消耗，缺点在于有锁就有死锁问题的发生，且只能串行执行性能肯定受到影响

逻辑过期方案： 线程读取过程中不需要等待，性能好，有一个额外的线程持有锁去进行重构数据，但是在重构数据完成前，其他的线程只能返回之前的数据。

白日905
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
黑马点评-07缓存击穿问题(热点key失效)及解决方案,使用互斥锁或设置逻辑过期时间
欢迎阅读我的博客
10-10 395
黑马点评-07缓存击穿问题(热点key失效)及解决方案,互斥锁和设置逻辑过期时间
Redis框架（八）：大众点评项目 逻辑过期时间处理缓存击穿
futurn_hero的博客
12-13 1340
SpringCloud章节复习已经过去，新的章节Redis开始了，这个章节中将会回顾Redis实战项目 大众点评 主要依照以下几个原则代码会同步在我的gitee中去，觉得不错的同学记得一键三连求关注，感谢： Redis优化-链接: RedisThreeStrategiesProject上一节已经讲了下互斥锁 互斥锁本身是ok的，但是将当前资源锁住，后面的用户 只能查询等待 有没有更好的解决方式那？ 这里可以设计逻辑过期时间我们定义一个逻辑过期时间 去单元测试中测试，向Redis注入热点信息 业务逻
Redis 逻辑过期策略设计思路
五只鸭子的专栏
04-18 2402
当我们平常使用Redis缓存的时候，会出现一种场景， redis的key到过期时间了，总是需要到数据库里面去查一遍数据再set回redis，这个时候如果数据库响应比较慢，那么就会造成用户等待，如果刚好并发比较大，则有可能给数据库造成巨大的压力，甚至导致服务不可用。当客户端发起GET请求的时候，首先判断Value是否有值。如果没有，说明物理过期时间已经过期了，这个时候执行LoadValue函数，一般是从数据库里面加载数据，然后再调用Set请求，将数据set进Redis，并将数据返回给Client。
Redis篇：缓存击穿及解决方案
最新发布
viperd的博客
04-23 1258
缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了（有可能是正好过期了），无数的请求访问会在瞬间给数据库带来巨大的冲击。常见的解决方案有两种：互斥锁逻辑过期。
redis——缓存雪崩、缓存穿透、缓存击穿
hayhead的博客
07-23 3434
redis
【Redis】缓存击穿问题及其解决方案
Decade_Faiz的博客
01-12 3643
第一个线程到来之后发现逻辑过期，于是获取互斥锁，再开启一个新线程去进行缓存重建。之后第一个线程成功缓存数据释放互斥锁之后，后面线程继续来访，发现命中缓存并且没有过期，返回重建数据。的实现思路就是在第一个线程到来的时候获取互斥锁，后面的线程来到之后尝试去获取互斥锁，获取失败，于是进行休眠重试。在线程1重建缓存的时候，线程2缓存又没命中，线程2也去重建缓存；：缓存击穿也叫做热点Key问题，就是少量被高并发访问并且缓存重建业务比较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的压力。
Redis
Hsy1121的博客
06-27 153
Redis
Redis 缓存穿透、缓存击穿工具类资源
09-07
Redis 缓存穿透的处理（缓存空值） Redis缓存击穿处理（互斥锁与逻辑删除方案） 封装为工具类，并适用于所有需要进行缓存穿透、击穿的方案，采用了泛型以及Lambda 函数式编程来完成编码
Redis缓存穿透缓存雪崩缓存击穿的原因和解决方案.docx
07-13
Redis缓存穿透、缓存雪崩、缓存击穿的原因和解决方案 Redis缓存穿透、缓存雪崩、缓存击穿是 Redis 缓存中常见的问题，它们可能会导致数据库的负载加大，影响系统的性能。本文将详细讨论这些问题的原因和解决方案。 ...
Redis缓存及热点key问题解决方案
08-19
Redis缓存是一种高效的缓存解决方案，用于加速应用程序的访问速度和降低数据库的负载。但是，Redis缓存也存在一些问题，例如热点key的问题。如果不妥善处理，可能会导致系统崩溃。因此，本文将详细介绍Redis缓存及...
Redis分布式锁存在的问题及解决方案（值得珍藏）
01-20
Redis分布式锁在实现跨进程、跨机器的互斥访问时，虽功能强大，但也存在一些常见问题。这些问题主要源于网络延迟、...总之，正确使用Redis分布式锁需深入理解其工作原理和潜在问题，并结合实际场景选择合适的解决方案。
redis-mutex:使用Redis的分布式互斥锁
08-04
Redis 互斥锁 Ruby 中使用 Redis 的分布式互斥锁。 支持阻塞和非阻塞语义。 这个想法来自。 概要 在下面的例子中，一次只有一个线程/进程/服务器可以进入锁定块。 RedisMutex . with_lock ( :your_lock_name ) ...
【Redis】分别从互斥锁与逻辑过期两个方面来解决缓存击穿问题
懒羊羊的博客
01-10 5096
都是为了以后要走的路而未雨绸缪
如何解决缓存击穿？
m0_54187478的博客
10-31 184
缓存击穿是指针对热门数据的缓存，由于并发访问，缓存失效的瞬间，大量请求直接穿透缓存，直接访问数据库，导致数据库压力骤增的情况。在系统启动时或非高峰期，预先加载热门数据到缓存中，以确保这些热门数据不会因为缓存失效导致击穿。预加载热门数据可以减少缓存失效瞬间的击穿情况。对于一些热门数据，可以设置成永不过期的缓存，保证数据不会因为过期而同时失效。同时，在缓存失效后，异步或定时刷新缓存。在缓存层次上添加一层前置缓存，例如本地缓存（内存），用于在缓存失效后提供一层缓冲，避免直接访问数据库。
缓存雪崩，缓存穿透，缓存击穿出现的原因及解决方案
qq_40822132的博客
04-07 4870
一、缓存雪崩 1.出现过程 假设有如下一个系统，高峰期请求为5000次/秒，4000次走了缓存，只有1000次落到了数据库上，数据库每秒1000的并发是一个正常的指标，完全可以正常工作，但如果缓存宕机了，或者缓存设置了相同的过期时间，导致缓存在同一时刻同时失效，每秒5000次的请求会全部落到数据库上，数据库立马就死掉了，因为数据库一秒最多抗2000个请求，如果DBA重启数据库，立马又会被新的请求打...
[springboot专栏]缓存雪崩、穿透、击穿的代码级解决方案
m0_67393619的博客
07-31 586
由于redis缓存设置的到期时间是统一的，没有办法根据缓存名称(value属性)分别设置缓存到期的时间，容易造成缓存雪崩。所以我们进行一个简单的改造。在改造之前我们先来看一下RedisCacheManager源码本专栏是一个连贯的系列专栏，如果存在看不懂的代码，请在本专栏中按自然排序查看之前的2-3篇文章。RedisCacheManager构造函数包含三个参数这个在之前的章节我们就配置过这个是默认的全局配置，针对所有缓存理解了上面的源码，下面的改造代码就不难理解了。@Datacaching。...
Java利用互斥锁解决缓存击穿问题
qq_54836465的博客
03-19 756
缓存击穿问题也叫热点key问题，就是一个被高并发访问并且缓存业务较复杂的key突然失效了，无数的请求访问在瞬间给数据库带来巨大的冲击。
缓存击穿及其解决办法
m0_53396342的博客
04-12 372
缓存击穿及其解决办法
Redis过期策略详解
热门推荐
想着百万年薪努力的小赵
06-17 8万+
redis过期策略
如何解决redis缓存击穿
05-04
Redis缓存击穿是指一个非常热门的key，在缓存过期的一刻，同时有很多的请求同时访问这个key，导致这些请求都会穿过缓存直接请求数据库，造成数据库压力剧增，甚至宕机。解决方案如下： 1. 设置热门缓存永不过期。对于一些热门数据，可以考虑设置成永不过期，不过期的数据可以通过定时任务等方式进行更新。 2. 使用布隆过滤器，过滤掉不存在的数据。对于一些不存在的数据，可以使用布隆过滤器进行过滤，避免对数据库的请求。 3. 加互斥锁（mutex）。在缓存失效时，多个线程同时访问数据库，容易造成数据库压力过大，可以使用互斥锁来解决。 4. 使用异步更新缓存。在缓存过期时，只让一个线程去更新缓存，其他线程等待更新完成后再读取缓存。 5. 限流降级。在缓存失效期间，可以通过限流降级的方式来减少对数据库的请求，保证数据库不会因为短时间请求量过大而宕机。 综上所述，解决Redis缓存击穿的方法有很多种，需要根据实际情况选择合适的方法。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值