redis分布式锁

最新推荐文章于 2024-05-11 09:54:36 发布
最新推荐文章于 2024-05-11 09:54:36 发布
阅读量83 收藏
点赞数 2
分类专栏： redis 文章标签： redis 分布式 数据库 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/piggyone123/article/details/134396393
版权

分布式锁


本文为学习redis时做的笔记，学习内容来自 黑马程序员Redis入门到实战教程，该教程是循序渐进的，所以不是一上来就讲完最后的解决方案了，请耐心看完

1. 问题分析

通过加锁可以解决在单机情况下的一人一单问题，但在集群下就不行了
image.png
在集群下，或者在分布式系统下，每个线程有自己的jvm,多个jvm存在，每个jvm都有自己的锁监视器，会有多个线程获得锁，可能出现安全问题，所以我们要想办法，让多个jvm使用同一把锁
即：
image.png
关键是让多个进程看到同一个锁，并且只有一个线程能拿到锁

2. 分布式锁

分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁
特点：

  • 多进程可见
  • 互斥
  • 高可用
  • 高性能
  • 安全性

image.png
可以看到虽然redis服务宕机后不能自动释放锁，但是redis从高可用和高性能上来讲是很好的，所以接下来学习一下如何基于redis实现分布式锁

3. 实现思路

实现分布式锁肯定要实现的两个方法是：获取锁和释放锁

  1. 获取锁：

使用set nx ex 获取锁，并设置超时时间

  • 互斥：确保只能有一个线程获取锁
  • 非阻塞：尝试一次，成功返回true，失败返回false
//添加锁，nx是互斥（即这个key不存在才能创建），ex是设置超时时间
set lock thread1 nx ex 10
  1. 释放锁：
  • 手动释放
  • 超时剔除：获取锁时添加一个超时时间
//释放锁，删除即可
del key

流程：
image.png

4. 初级版本

先写一个锁的接口

public interface ILock {

    /**
     * 获取锁
     *
     * @param timeoutSrc
     * @return
     */
    boolean tryLock(long timeoutSrc);

    /**
     * 释放锁
     */
    void unlock();

}

写对应的实现类，实现获取锁和释放锁的方法,记着获取该线程的唯一标识，用Thread.currentThread().getId()

import org.springframework.data.redis.core.StringRedisTemplate;
import java.util.concurrent.TimeUnit;


public class SimpleRedisLock implements ILock {

    private StringRedisTemplate stringRedisTemplate;
    private String name;

    public SimpleRedisLock(StringRedisTemplate stringRedisTemplate, String name) {
        this.stringRedisTemplate = stringRedisTemplate;
        this.name = name;
    }

    private static final String KEY_PREFIX = "lock:";

    @Override
    public boolean tryLock(long timeoutSrc) {
        //作为线程的唯一标识，获取线程的id
        long threadId = Thread.currentThread().getId();
        //当这个key不存在时再执行，实现了互斥
        Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId + "", timeoutSrc, TimeUnit.SECONDS);
        //包装类怕有空指针异常
        return Boolean.TRUE.equals(flag);
    }

    @Override
    public void unlock() {
        stringRedisTemplate.delete(KEY_PREFIX + name);
    }
}

接下来在服务层改写原先的创建锁逻辑

Long userId = UserHolder.getUser().getId();
//创建锁对象
SimpleRedisLock redisLock = new SimpleRedisLock(stringRedisTemplate, "order" + userId);
//获取锁方法
boolean lockFlag = redisLock.tryLock(1200);
//判断是否获取成功
if (!lockFlag) {
    return Result.fail("不要重复下单");
}

//事务方法执行起来可能会出现异常，但最后都要释放锁,所以try-catch起来
try {
    //获取当前的代理对象(事物)
    IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
    return proxy.createVoucherOrder(voucherId);
} finally {
    redisLock.unlock();
}

现在在apifox中用同一个用户的token向不同线程的程序发送请求
image.png
image.png
image.png
同一个用户在不同线程发送请求，只有其中一个请求能获得锁，库存也只减少了1，实现了分布式锁的功能

5. 误删问题

image.png
有一种极端情况，线程1获取到锁，但业务阻塞时间太长，已经超过了锁的超时释放时间，锁被释放了，这时线程2获取到锁，线程2执行业务时线程1业务完成，去释放锁，就把线程2的锁释放了，这时线程3也获取到锁…
出现了线程安全问题 ,最关键的就是在释放锁的时候要判断一下是不是自己线程的锁

image.png

详细思路：获取锁的时候存入线程标识，在释放锁的时候获取线程标识并判断是否一致，如果不一致，就什么也不做，就可以避免误删其他线程的锁

5.1 解决

修改之前的分布式锁实现，满足：

  1. 在获取锁时存入线程标识（只用线程id可能会出现id冲突的情况，所以用UUID+线程id表示）
  2. 在释放锁时先获取锁中的线程标识，判断是否与当前线程标识一致
  • 如果一致则释放锁
  • 如果不一致则不释放锁
import cn.hutool.core.lang.UUID;
import org.springframework.data.redis.core.StringRedisTemplate;

import java.util.concurrent.TimeUnit;


public class SimpleRedisLock implements ILock {

    private StringRedisTemplate stringRedisTemplate;
    private String name;

    public SimpleRedisLock(StringRedisTemplate stringRedisTemplate, String name) {
        this.stringRedisTemplate = stringRedisTemplate;
        this.name = name;
    }


    private static final String KEY_PREFIX = "lock:";
    private static final String ID_PREFIX = UUID.randomUUID().toString(true)+"-";
    @Override
    public boolean tryLock(long timeoutSrc) {
        //线程标识
        String threadId =ID_PREFIX+ Thread.currentThread().getId();
        //当这个key不存在时再执行，实现了互斥
        Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId , timeoutSrc, TimeUnit.SECONDS);
        //包装类怕有空指针异常
        return Boolean.TRUE.equals(flag);
    }

    @Override
    public void unlock() {
        //判断线程标识是否一致
        //当前线程标识
        String threadId =ID_PREFIX+ Thread.currentThread().getId();
        //锁中的标识
        String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);

        if (threadId.equals(id)) {
            //标识一致再释放锁
            stringRedisTemplate.delete(KEY_PREFIX + name);
        }
        //标识不一致就不管了


    }
}

修改了线程标识的获取实现逻辑，并在释放锁时判断线程标识和锁中的标识是否一致

测试：
线程1获取到了锁
image.png
image.png

线程2获取到了锁
image.png
image.png

因为线程1的锁的键值对被我们删除，后来在释放锁时线程标识和锁中的标识就对不上，就不能删除线程2对应的锁，而线程2对应的锁能被线程2释放

6. 分布式锁的原子性问题

image.png
还有一种特殊情况，线程1执行完业务并判断锁标识与当前锁标识一致，准备释放锁时发生了阻塞，时间太长导致锁超时释放，线程2这时获取到了锁，在执行业务时，线程1不阻塞了，就把当前的锁释放了（加了uuid锁还被删的原因：前边判断的时候锁还是自己的）。。。
出现了线程安全问题，我们可以用redis事物和乐观锁实现，但这种做法就复杂很多了
推荐使用lua脚本

6.1 redis的lua脚本

lua是一种编程语言，redis提供了lua脚本功能，在一个脚本中编写多条redis命令，确保多条命令执行时的原子性，lua基本语法参考网站： https://www.runoob.com/lua/lua-tutorial.html

6.1.1 简单语法

重点介绍redis提供的调用函数，语法如下：

redis.call('命令名称','key','其他参数'......)

例如我们要执行set name zhuyi,则脚本是这样的：

redis.call('set','name','zhuyi')

如我们要先执行set name zhuyi，再执行get name,则脚本是这样的：

redis.call('set','name','zhuyi')
Local name = redis.call('get','name')
return name

写好脚本之后，要去调用脚本，调用脚本的常见命令如下：
image.png
例如，我们要执行redis.call('set','name','zhuyi')这个脚本，语法如下：
image.png

如果脚本中的key，value不想写死，可以作为参数传递。key类型的参数会放入KEYS数组，其他参数会放入ARGV数组，在脚本中可以从KEYS和ARGV数组获取这些参数：

eval "return redis.call('set',KEYS[1],ARGV[1])" 1 name lvhan

其中name对应KEYS[1]，lvhan对应ARGV[1]

6.1.2 脚本书写释放锁的业务流程

  1. 获取锁中的线程标识
  2. 判断是否与指定的标识（当前线程标识）一致
  3. 如果一致则释放锁（删除）
  4. 如果不一致则什么都不做

-- 比较线程标识与锁中的标识是否一致
if(redis.call('get',KEYS[1]) == ARGV[1]) then
--释放锁 del key
return redis.call('del', KEYS[1])
    end
    return 0

先判断当前线程标识与锁中的标识是否一致，一致就释放锁，不一致就不管

6.2 java调用lua脚本改造分布式锁

RedisTemplate调用lua脚本的api为：
image.png
其中，eval相当于execute函数，函数中的script相当于脚本，keys相当于KEYS数组，args相当于ARGV数组，numkeys相当于key的参数个数，也就是keys集合的长度

  1. 首先在idea里下载lua脚本的插件：EmmyLua

image.png

  1. 在resource文件夹里创建lua文件并把写好的脚本传入

image.png

  1. 改写释放锁的逻辑,不用自己写逻辑，使用lua脚本

使用execute函数
image.png
脚本类型为RedisScript,这是个类就要去加载lua文件，如果我们每次释放锁都要去读取文件，产生io流，性能不好，所以我们应该提前定义脚本
image.png
（该页面通过ctrl+h查看）
RedisScript是一个接口，我们应该使用它的实现类DefaultRedisScript,T是返回类型
3.1. 初始化脚本
通过静态代码块，这个类一加载，脚本初始化就完成了
setLocation()是设置lua脚本位置的，ClassPathResource是在resource目录下寻找

private static final DefaultRedisScript<Long> UNLOCK_SCRIPT;

//初始化脚本
static {
    UNLOCK_SCRIPT = new DefaultRedisScript();
    //读取文件位置，classpath就是resource
    UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
    UNLOCK_SCRIPT.setResultType(Long.class);
}

接下来在释放锁的逻辑中调用lua脚本

@Override
public void unlock() {
    //调用lua脚本
    //Collections.singletonList()单体集合
    //释放锁如果不成功，说明锁已经被别人删了，也不用管，所以不用管返回值
    stringRedisTemplate.execute(
        UNLOCK_SCRIPT,
        Collections.singletonList(KEY_PREFIX + name),
        ID_PREFIX + Thread.currentThread().getId());
}
  • Collections.singletonList()是创建单体集合的方法
  • 释放锁成功了就成功了，如果不成功，说明锁已经被别人删了，也不用管，所以不用管返回值

测试：
image.png
线程1获取到锁
image.png
线程1的锁，现在删除这条数据
image.png
所以线程2获取到锁
image.png
线程2的锁
image.png
线程1执行完释放锁操作，但是并没有删除redis中的数据
image.png
线程2执行完释放锁操作，成功删除

现在判断和删除的操作是在脚本中写的，能保证原子性

7. Redisson

7.1 上边实现的分布式锁存在的问题

基于setnx实现的分布式锁存在以下问题：

  • 不可重入

同一个线程无法多次获取同一把锁，如果a方法在方法里要去调用b方法，a方法先获取锁，再去调用b方法，但b方法也要获取这个锁，就获取不到了

  • 不可重试

我们之前获取的锁只尝试一次就返回false,没有重试机制，在很多情况下是不可接受的

  • 超时释放

可能会有其他的安全隐患，时间长了短了都不行

  • 主从一致性

如果Redis提供了主从集群（主写从读），主从同步存在延迟，当主岩机时，如果从并同步主中的锁数据，可能会有多个线程拿到锁

不推荐亲自实现，我们使用Redisson

7.2 Redisson介绍

Redisson是一个在Redis基础上实现的java驻内存数据网格，提供了一系列的Java常用对象，提供了很多分布式服务，其中就有各种分布式锁的实现
image.png
官网：https://redisson.org
github：https://github.com/redisson/redisson

7.3 入门

有两种方式，不推荐使用springboot-starter那种，因为会替代spring官方提供的对redis的配置和实现，我们自己写配置

  1. 先引入依赖
<dependency>
  <groupId>org.redisson</groupId>
  <artifactId>redisson</artifactId>
  <version>3.13.6</version>
</dependency>
  1. 配置redisson客户端
@Configuration
public class RedissonConfig {
    @Bean
    public RedissonClient redissonClient() {
        //配置类
        Config config = new Config();
        //添加redis地址，这里添加了单点的地址，也可以使用config.useClusterServer()添加集群地址
        //有密码还要加密码
        config.useSingleServer().setAddress("redis://localhost:6379");
        //创建客户端
        return Redisson.create(config);
    }
}
  1. 使用Redisson的分布式锁

修改获取锁和释放锁的逻辑，通过redisson客户端的方法获取锁，如果获取不到就不重试了，所以redisLock.tryLock()里面我们不传入时间

//创建锁对象
RLock redisLock = redissonClient.getLock("lock:order:" + userId);
//获取锁方法
boolean lockFlag = redisLock.tryLock();
//判断是否获取成功
if (!lockFlag) {
    return Result.fail("不要重复下单");
}

//事务方法执行起来可能会出现异常，但最后都要释放锁,所以try-catch起来
try {
    //获取当前的代理对象(事物)
    IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
    return proxy.createVoucherOrder(voucherId);
} finally {
    redisLock.unlock();
}

7.4 redisson的可重入锁

使用set nx 实现的分布式锁无法实现一个线程多次获取同一把锁，我们用redisson实现

7.4.1 原理

当我们获取锁的时候，当我们判断这个锁已经有人的情况下，判断一下是否是同一个线程，如果是同一个线程，我们也让它获取锁，需要一个计数器记录一下重入的次数，在获取锁时这个数不断加1，释放锁时这个数不断减1

image.png
在redis里我们不光要记录线程标识，还要记录重入的次数，所以我们要用到hash结构，其中key是锁的名称，field是线程标识，value是重入的次数

image.png
在内部被调用的方法里边，释放锁的时候是不能直接删除锁，要使重入的次数减1，当所有的业务执行完，走到最外层方法的时候，释放锁才能删除锁，即等到重入的次数为0时

image.png

  • 获取锁时先判断锁是否存在，不存在就获取锁并添加线程标识，设置锁有效期，如果存在就判断锁标识是否是自己，是的话锁计数加1，不是的话就失败了。
  • 释放锁时，先判断锁是否是自己的，是的话锁计数减1，判断锁计数是否为0，不为0要重置有效期，为0要去释放锁

为了保证原子性，用lua脚本写逻辑

获取锁的lua脚本：

local key = KEYS[1]; --锁的key
local threadId = ARGV[1]; --线程唯一标识
local releaseTime = ARGV[2]; --锁的自动释放时间

--判断锁是否存在
if(redis.call('exists',key) == 0 ) then
  --不存在，直接获取锁
  redis.call('hset',key,threadId,'1');
  --设置有效期
  redis.call('expire',key,releaseTime);
  return 1;--返回结果
end;
--锁存在，判断是否在同一个线程
if(redis.call('hexists',key,threadId) == 1 ) then
  --在同一个线程，重入次数加1
  redis.call('hincrby',key,threadId,'1');
  --设置锁有效期
  redis.call('expire',key,releaseTime);
  return 1;--返回结果
end;
return 0; --走到这一步说明不在当前获取锁的线程，获取锁失败

获取锁的lua脚本：

--释放锁
local key = KEYS[1]; --锁的key
local threadId = ARGV[1]; --线程唯一标识
local releaseTime = ARGV[2]; --锁的自动释放时间
--判断锁是否是自己的
if(redis.call('hexists',key,threadId) == 0 ) then
    return nil;
end;
--是自己的,锁计数减1
local count = redis.call('hincrby',key,threadId,-1);
--判断锁计数是否为0
if(count > 0) then
    --大于0说明不能释放锁，重置有效期
    redis.call('expire',key,releaseTime);
    return nil;
else -- 等于0说明可以释放锁
    --释放锁
    redis.call('del',key);
    return nil;
end;

7.5 可重试

原理：
利用信号量和pubsub功能实现等待、唤醒、获取锁失败的重试机制
第一次尝试获取锁失败后，不是立即失败，而是通过订阅消息，等待释放锁的消息，而成功获取锁的线程在释放锁的时候会发出这个消息，但是也不是无限的重试，有一个等待时间，如果超出这个等待时间，就不再尝试。因为这种等待唤醒的机制，cpu占用不高

开门狗机制：watchdog,超时续约，当线程成功获取锁之后，会开启一个定时任务，每隔一段时间就去重置锁的超时时间

7.6 主从一致

获取联锁

RLock lock1 = redissonClient.getLock("order:1");
RLock lock2 = redissonClient.getLock("order:2");
RLock lock3 = redissonClient.getLock("order:3");
RLock multiLock = redissonClient.getMultiLock(lock1, lock2, lock3);

原理：
多个独立的redis节点，必须在所有节点都获取重入锁，才算获取锁成功

PiggyOne123
关注
  • 2
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
redis 分布式锁
weixin_58361879的博客
06-20 790
redis手写分布式锁
浅析Redis分布式锁
12-16
前期考虑的方案有采用ZooKeeper分布式任务,Quartz分布式任务调度,但是由于Zookeeper需要增加额外组件,Quartz需要增加表,并且项目中现在已经有Redis这一组件存在,所以考虑采用Redis分布式锁的情况来完成分布式任务...
Redis分布式锁
给自己一个smile
03-29 1225
Redis分布式锁
Redis 分布式锁
weixin_43844718的博客
08-23 546
Redis分布式锁应用。提示：以下是本篇文章正文内容，下面案例可供参考在极端的情况下，都会有锁失效或锁冲突的情况出现，建议对分布式锁不要强依赖，没有绝对可靠的分布式锁，分布式锁需要与业务的联动配合更加切实可行，不要造成不必要的损失。
Redis分布式锁及其常见问题解决方案
栗筝i的博客
09-21 2963
Redis 提供了一种简单有效的分布式锁实现方式。其基本思想是使用 Redis 的 SETNX 命令，这个命令可以在键不存在时设置值，如果键已存在则不做任何操作。通过这个原子操作，我们可以实现在多个节点之间的互斥访问。 然而，虽然 Redis 分布式锁的实现相对简单，但在实际使用中还需要考虑很多问题，例如锁的超时和续期问题、锁的公平性问题、网络分区的问题等。在接下来的文章中，我们将详细介绍这些问题以及解决方案。
Redis分布式锁存在的问题以及解决方式
个人博客，欢迎收藏。https://xiaoaozz.github.io/
01-18 1183
带你一起解决Redis分布式锁存在的问题。
三、详解Redis分布式锁&Redisson分布式锁
2301_77203215的博客
01-23 1120
在传统的java进程中，我们常常用Synchronized或者ReentrantLock来对临界区进行加锁,防止多个线程之间并行访问,导致数据读写异常。但是这种锁的粒度仅限于当前jvm中，在工业生产环境下，往往一个web项目会部署多台机器，也就意味着会有多个jvm。那么这几个jvm是独立的，这就导致上述的锁失效。分布式锁是一种在分布式系统环境下，通过多个节点对共享资源进行访问控制的机制。
Go语言实现Redis分布式锁
m0_57408211的博客
04-04 1027
本文将基于go语言，使用了一个常用的go Redis客户端一步一步探索与实现一个简单的Redis分布式锁。SETNX 命令用于在Redis中设置某个不存在的键的值。如果该键不存在，则设置成功，如果该键存在，则设置失败，不作任何动作。基于此可以实现一种简单的抢占机制。先连接redis。新建lock.go文件。创建lock结构体，加锁和解锁方法。
Java Redis分布式锁的正确实现方式详解
08-25
主要介绍了Java Redis分布式锁的正确实现方式详解,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
redis分布式锁工具类
09-26
现在很多项目单机版已经不满足了，分布式变得越受欢迎，同时也带来很多问题，分布式锁也变得没那么容易实现，分享一个redis分布式锁工具类，里面的加锁采用lua脚本（脚本比较简单，采用java代码实现，无须外部调用...
PHP Redis分布式锁
03-23
使用Redis分布式锁时，需要注意设置合适的超时时间和锁的释放机制，以防止因为锁未及时释放导致的资源浪费或系统阻塞等问题。 另外，还需要考虑锁的粒度和范围，尽量减小锁的范围，避免锁的持有时间过长或锁的竞争...
redis分布式锁.zip
10-18
本资源为一步一步实现redis分布式锁的demo，利用redis实现高可用的分布式锁，规避各种坑、坑、坑！
为什么Redis6.0引入了多线程
IT深耕十余载，大道之简
05-11 258
总的来说，Redis 6.0引入多线程是为了提高性能、降低延迟、更好地利用CPU资源，并保持Redis的简单性和高性能特点。这些改进有助于Redis更好地应对不断增长的数据量和并发量需求，同时保持其稳定性和可靠性。Redis 6.0引入多线程的决策是基于其性能优化和适应现代硬件架构的考虑。
在Redis中Lua脚本为什么可以保证原子性
IT深耕十余载，大道之简
05-11 203
综上所述，Redis通过其单线程模型、内置Lua解释器、Lua脚本的原子性执行以及减少网络开销等机制，保证了Lua脚本在Redis中执行的原子性。这使得Lua脚本成为Redis中一种强大的工具，可以用于实现复杂的数据操作、事务处理、乐观锁、排他锁等需要原子性保证的场景。在Redis中，Lua脚本的原子性保证主要源于Redis的内部实现机制和Lua脚本的执行方式。
Redis 实战之客户端属性
奔走的蚂蚁的博客
05-06 799
服务器状态结构使用 clients 链表连接起多个客户端状态， 新添加的客户端状态会被放到链表的末尾。客户端状态的 flags 属性使用不同标志来表示客户端的角色， 以及客户端当前所处的状态。输入缓冲区记录了客户端发送的命令请求， 这个缓冲区的大小不能超过 1 GB。命令的参数和参数个数会被记录在客户端状态的 argv 和 argc 属性里面， 而 cmd 属性则记录了客户端要执行命令的实现函数。
Redis 实战之命令请求的执行过程
奔走的蚂蚁的博客
05-07 1099
一个命令请求从发送到完成主要包括以下步骤： 1. 客户端将命令请求发送给服务器；2. 服务器读取命令请求，并分析出命令参数；3. 命令执行器根据参数查找命令的实现函数，然后执行实现函数并得出命令回复；4. 服务器将命令回复返回给客户端。serverCron 函数默认每隔 100 毫秒执行一次， 它的工作主要包括更新服务器状态信息， 处理服务器接收的 SIGTERM 信号， 管理客户端资源和数据库状态， 检查并执行持久化操作， 等等。
Redis过期删除策略和内存淘汰策略有什么区别？
最新发布
巴卡巴卡哇的博客
05-11 472
Redis过期删除策略和内存淘汰策略有什么区别？
redis 缓存一致性，缓存穿透，缓存雪崩，缓存击穿
dxh9231028的博客
05-04 940
1.缓存一致性：缓存一致性就是通过各种方法保证缓存与数据库信息一种，其中最多的办法就是想尽一切办法对过期key进行清除，以保证redis和数据库信息一只，其中就包括了中提到的内存淘汰策略，过期key的清除等等，当然也包括在代码中进行手动清除过期key，不过手动清除时需要注意要保证数据库的更新和redis的清除都成功完成，可以使用的方法包括，使用事务，使用相关服务将redis和数据库进行整合，或者只操作redis，再由redis操作数据库等等。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值