Redis面试总结

最新推荐文章于 2025-12-03 16:51:03 发布
原创 最新推荐文章于 2025-12-03 16:51:03 发布 · 148 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#redis #面试 #java

本文介绍了Redis中的五种数据结构及其应用场景，包括String、List、Hash、Set和ZSet，并详细阐述了Redis的两种持久化机制：RDB和AOF，以及它们各自的优缺点。

Redis数据结构以及使用场景

1.String
Redis中String类型的数据最大只能是512M
1、计数器功能，我们可以使用incr命令实现自增操作,来计数。例如我们可以统计文章的阅读量、粉丝数量等
2、系统中的一些配置值、Token令牌信息等
3、session共享, 在分布式系统中，由于有多台服务器，请求分发，每次分发到的目标服务器可能都不一样,那么这时候我们就需要利用一个中间件来保存session的状态，我们就可以把session保存在redis中
4、限流，就是有时候我们需要对某些用户、某些接口、某些IP地址进行限流，即比如每分钟只能访问多少次等
2.List
字符串列表，按照插入顺序排序。
1、消息队列，可以使用lpush + brpop命令实现阻塞队列
2、像一些分页查询的功能，如果数据保存在缓存中，也可以使用list,对应的命令: lrangkey 0 19分页获取
3.Hash
哈希是一个String类型的field以及value的映射表,类似Java的Map

{
 hash1 : { name: "zhangsan", age: 20 },
 hash2 :{ name: "lisi", age: 30 },
}
 

1、可以存储一些对象信息,如用户信息、订单信息等
2、购物车功能
    使用用户ID作为缓存Key
    使用商品编码skuCode作为hashKey
    使用商品信息作为hashValue
4.Set
无序集合，集合里面的元素都是唯一的，也就是说集合里面不会出现重复元素
1.社交软件的共同好友，共同爱好等。如微博的共同好友
2.统计访问我们网站的ip地址
3.抽奖功能，返回随机数功能
5.ZSet
sorted set,和set一样也是不允许重复的，不同的是每个元素都会关联一个score分数，内部是基于score进行排序的（从小到大）
zset里面元素不会重复，但里面的score分数是可以重复的
排行榜功能，如游戏的用户得分排行榜，学生的成绩排行等。

Redis的持久化机制有哪些?有哪些优缺点?

1、RDB
RDB (redis database)持久化，是指在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它是Redis默认的持久化方式。执行完操作后，在指定目录下会生成一个dump.rdb文件，Redis 重启的时候，通过加载dump.rdb文件来恢复数据。
配置（redis.conf）
 默认提供了三种会触发rdb持久化的条件
    save 900 1 900秒之内至少有一个key被改变
    save 300 10 300秒之内至少有十个key被改变
    save 60 10000
    save " "关闭rdb持久化功能

触发机制
    手动触发
        save（同步）
            save时只管保存，其他不管，save是一个阻塞式命令，即当服务器接收了一条save命令之后就会开始拍摄快照，在此期间不会再去处理其他的请求，其他请求会被挂起直到备份结束，应该避免使用。

        bgsave（异步）
            redis会在后台异步进行快照操作，快照操作同时还可以响应客户端请求，与save命令区别就在于bgsave不会阻塞主进程处理的操作。Redis会单独创建(Fork) 一 个子进程来进行持久化，先将数据写入到一个临时文件中，待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。


    自动触发
        save  m n m秒内数据集存在n次修改时，自动触发bgsave


优点
    1、如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比A0F方式更加的高效
    2、与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些
    3、RDB很适合用于灾备，单文件很方便就能传输到远程的服务器上;
    4、可以定期备份rdb文件，直接写个脚本就好了，很方便

缺点
    1、没办法做到实时持久化/秒级持久化
    2、最后一次持久化后的数据可能丢失
    3、rdb需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能导致redis在一些毫秒级不能响应客户端请求
2、AOF
全称叫" append only file", aof是以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录) ,只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，redis重启的话根据日志文件的内容将写指令从头到尾执行一次以完成数据的恢复。AOF方式持久化默认保存的是appendonly.aof文件。它主要解决数据持久化的实时性问题。默认是不开启的。
配置
    aof持久化开关默认是关闭的 appendonly no
    aof备份的文件名 appendfilename "appendonly.aof"
    appendsync everysec  持久化策略
    默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发重写。
    auto-aof-rewrite -min-size 64mb
    auto-aof-rewrite-percentage 100

原理
    aof仿式持久化通过保存redis执行时候的所有写操作命令，注意，读操作命令不追加，将写命令追加到appendonly.aof文件中，理论上只要保存了所有写操作命令，那么恢复时将这些命令从头到尾再执行一次就可以从正常恢复数据。

AOF持久化策略
    appendfsync always: Always: 同步持久化，每次发生数据变更会立即记录到磁盘，性能较差但数据完整性比较好，always会严重影响服务器的性能;
    appendfsync everysec: Everysec:默认就是此方式，异步操作，每秒记录，如果一秒内宕机，有数据丢失;
    appendfsync no:从不同步

重写机制
    aof采用文件追加方式，文件会越来越大，为避免出现此种情况，redis新增了重写机制，当aof文件的大小超过所设定的阈值时，Redis就会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集。当然我们也可以使用命令bgrewriteaof手动告诉redis进行aof文件的重写，这样可以有效减小aof文件的体积。
        重写原理
            redis会fork出一个子进程来对aof文件进行重写，原理跟快照持久化命令bgsave的工作原理类似，值得注意的是，进行aof文件重写时，如果原来的aof文件体积已经非常大，那么重写aof并删除旧aof文件的过程将会对Redis的性能造成较大的影响。
            auto-aof-rewrite-percentage:配置当aof文件需要比旧aof文件增大多少时才进行重写
            auto-aof-rewrite-min-size:配置当aof文件需要达到多大体积时才进行重写
            只有这两配置都达到时，才会进行重写



优点
    1、数据的一致性和完整性更高
    2、使用默认的持久化策略:每秒同步一次，Redis 最多只会丢失1秒的数据;
    3、aof文件的格式可读性较强，同时还可以检查aof文件中的错误并进行修复;

缺点
    1、对相同的数据集来说，aof文件的体积通常要大于rdb文件的体积，恢复速度慢于rdb;

加载流程
在这里插入图片描述

如果存在dump.rdb文件和aof文件的话，会先加载aof文件
3、总结
redis允许同时存在rdb和aof两种持久化方式，但是重启时会优先加载aof文件;
如果在项目中只是将redis作为缓存服务器的话，我们其实可以不用进行持久化，因为缓存对数据敏感性没那么强;
aof持久化方式最多只会丢失一秒的数据，但是这带来了很多额外的I0操作，其次就是重写造成的阻塞不可避免，所以应该尽量减少aof重写的频率，建议将参数auto aof-rewrite-min-size修改为5G或者更大;
Redis高频面试基本问题与知识点整理
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
04-07 173万+
对Redis一些重点内容进行整理总结用于查缺补漏，应对各大互联网大厂面试方向题库
Redis常见面试题总结
夏日 の blog
08-31 2787
listpack 中每个节点不再像压缩列表一样包含前一个节点的长度，但还是用一块连续的内存空间来紧凑地保存数据，并且为了节省内存的开销，listpack 节点会采用不同的编码方式保存不同大小的数据。当我们向 listpack 加入一个新元素的时候，不会影响其他节点的长度字段的变化，从而避免了压缩列表的连锁更新问题。避免额外的检查开销，AOF 记录日志不会对命令进行语法检查；在命令执行完之后再记录，不会阻塞当前命令的执行。这样也带来了风险如果刚执行完命令 Redis 就宕机会导致对应的修改丢失；
redis面试总结
正在努力工作的搬砖人
02-24 3075
为啥单线程redis那么快？ 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速； 数据结构简单，对数据操作也简单； 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗； 使用多路 I/O 复用模型，非阻塞 IO。 怎么理解单线程？ 首先咱得知道Redis是单线程。 主要是指 Redis的网络 IO 和键值对读写是由一个线程来完成，这也是 Redis 对外提供键值存储服务
redis面试题总结（附答案）
学Java，找哪吒
06-06 11万+
Redis中间件实战系列，打造精品专栏。
Redis面试总结（一）
YMY哈的博客
10-30 1501
Redis面试总结
20道经典Redis面试题
热门推荐
ANGEL CITY
05-06 24万+
前言 整理了20道经典Redis面试题，希望对大家有帮助。 1. 什么是Redis？它主要用来什么的？ Redis，英文全称是Remote Dictionary Server（远程字典服务），是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。 与MySQL数据库不同的是，Redis的数据是存在内存中的。它的读写速度非常快，每秒可以处理超过10万次读写操作。因此redis被广泛应用于缓存，另外，Redis也经常用来做分布式锁
Redis面试总结，助力大厂
一只小菜鸡的博客
06-12 4172
Redis面试总结（非基础）Redis简介Redis 基本数据类型 Redis简介 Redis 是一种NoSql，非关系型数据库，是字典结构的存储方式，采用 key-value 存储。key 和 value 的最大长度限制 是 512M。 Redis 基本数据类型 ...
Redis 面试核心知识点总结，一文读懂 Redis！
2403_85207115的博客
04-21 1150
不同的数据类型适用于不同的应用场景，如 String 常用于存储简单的键值对，List 适用于实现队列和栈，Hash 适合存储对象等。这种方式主要用于解决在更新数据库后，缓存中的旧数据可能导致的数据不一致问题。通过数据分片将数据存储在不同的节点上，节点间通过 Gossip 协议进行通信和数据同步，实现了集群的水平扩展和高可用性。Redis 事务是一组命令的集合，它可以保证这组命令在执行过程中不会被其他客户端的命令打断，即这些命令要么全部执行，要么全部不执行。（本文大部分内容也总结于这篇文章）
Redis面试篇
weixin_49429082的博客
10-23 1283
介绍了Redis面试相关内容，包括缓存、持久性、数据过期、内存淘汰、主从复制、主从同步、哨兵、分片集群等方面
精选资源
2020面试题总结Redis篇.pdf
01-27
### Redis核心知识点详解 #### 一、Redis的优势 Redis作为一种高性能的键值对存储系统，在IT行业中被广泛应用。它的优势主要包括： 1. **高速访问**：由于数据存储在内存中，Redis提供了类似HashMap的快速访问...
redis面试题汇总
qq_57222058的博客
08-15 798
比如，客户端A和B都在同一时刻读取了mykey的原有值，假设该值为10，此后两个客户端又均将该值加一后set回Redis服务器，这样就会导致mykey的结果为11，而不是我们认为的12。RENAME命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。
Redis服务安装自启动(Windows版)
2509_94199043的博客
11-29 876
一般来说，一些中大型企业都会去采用 Linux 服务器来部署 Redis，而且 Redis 官方并没有提供 [Windows 版本](https://gitcode.com/gh_mirrors/wi/windows/overviewutm_source=highlight_word_gitcode&word=windows&isLogin=1 "Windows 版本")的安装包。
RedisStudio-en-0.1.5.exe 安装步骤 详细教程（附安装包）
IDOlaoluo的博客
12-03 75
RedisStudio 是一个，主要面向 Windows 用户。
redis基本类型 5种基本类型
yeshihouhou的博客
11-30 257
List的另一个应用就是消息队列，可以利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。我们在谈基础数据结构时，讨论的是存储值的数据类型，主要包括常见的5种数据类型，分别是：String、List、Set、Zset、Hash。Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
使用Redisson实现同一业务类型串行执行的分布式锁方案,解决并发问题
weixin_42759398的博客
12-03 98
摘要：本文介绍了使用Redisson实现同一业务类型串行执行的分布式锁方案。通过为每个bussType创建独立锁（如code:lock:order），确保相同业务类型请求串行处理，不同业务类型并行执行。方案采用Redisson的RLock实现自动续期、超时释放和死锁防护，比原生Redis锁更稳定。实现步骤包括：1)引入Redisson依赖；2)配置Redis连接；3)改造Service方法，在获取锁后执行核心业务逻辑。关键特性包括细粒度锁、非阻塞获取、自动续期（默认10秒）和超时释放（30秒），有效解决并发
Redis 通信协议（RESP）
最新发布
人工智能专业学生
12-03 400
摘要： RESP是Redis的通信协议，具有简单、高效、可读性强等特点，支持Pipeline和多种数据类型。RESP2包含五种基础类型：简单字符串（+）、错误（-）、整数（:）、批量字符串（$）和数组（*），适用于命令参数和返回结果。Redis6引入RESP3，扩展了Map、Set等复杂类型，但默认仍兼容RESP2。RESP的优势包括解析简单、高性能、支持批处理，且底层通信通过前缀标识数据类型（如*3\r\n$3\r\nSET）。面试常考察协议选择原因、二进制安全性及RESP3改进。
redis清理缓存
2509_94198891的博客
12-01 294
到这里就清除缓存完毕了，不需要重启redis，不过值得注意的是，你们服务器的缓存数据是否重要，是否可以全部清除，一定要确定清楚了以后才执行清空缓存的命令，如果不确定能不能清除，最好先确定了以后才清楚，否则不要轻易清除。如果你们的项目用到redis啦，虽然设置了过期时间，但有时候修改bug，仍然需要及时清空缓存，去读数据库的数据，所以这篇文章讲解如何清除redis的缓存。到这里就清除完毕，不需要重启，不过大家要注意，你们服务器的缓存数据是否重要，是否可以清除，一定要确定清楚，否则不要轻易清除。
redis面试题总结详细版
04-28
<think>好的，我现在需要处理用户关于Redis面试题总结的请求。用户提到想要详细版的内容，特别是关于分布式缓存、持久化、高可用这几个方面。首先，我需要回顾之前的对话历史，确保回答的一致性和连贯性。 用户之前询问了Redisson分布式锁的实现原理，我给出了详细的解答，并生成了相关问题。现在用户希望获取Redis的面试题总结，这应该是一个更广泛的主题，涵盖多个核心模块。根据用户提供的引用内容，我需要整合这些信息，并补充更多相关知识点。 首先，用户提供的引用中提到了缓存雪崩、击穿、穿透，以及Redis的持久化、多线程特性等。这些内容需要被组织到相应的面试题中。同时，用户特别提到需要详细版，因此每个问题都需要深入解释，可能包括原因、解决方案、相关配置命令等。 接下来，我需要考虑如何结构化回答。通常，面试题总结会按主题分类，比如基础概念、数据结构、持久化、高可用、分布式缓存问题、性能优化等。每个类别下列出常见问题，并给出详细解答。 对于分布式缓存部分，需要涵盖雪崩、击穿、穿透，以及对应的解决方案。比如，缓存雪崩的均匀过期时间设置，Redis集群的高可用部署。这部分用户已经提供了一些引用内容，需要整合进去。 持久化方面，用户引用中提到了RDB和AOF，但需要更详细地解释两者的区别、优缺点，配置命令，以及如何选择。此外，混合持久化是Redis 4.0后的新特性，也应该包含进去。 高可用部分，主从复制、哨兵模式、集群模式是重点。需要详细说明每种模式的原理、搭建步骤、优缺点，以及适用场景。用户提到RedLock算法，这在分布式锁部分已经涉及，但需要在高可用中进一步说明。 另外，用户引用的内容中提到了Redis的多线程特性，特别是在6.0版本后的变化。需要区分IO多线程和命令执行单线程，解释为什么命令执行仍然是单线程，以及这样设计的好处，比如避免并发问题。 还需要考虑其他常见面试题，比如Redis的数据结构、内存管理、淘汰策略、事务支持、与Memcached的比较等。这些内容用户没有直接提到，但属于Redis面试题的常见部分，应该包含在详细版总结中。 在组织答案时，要确保每个问题都有清晰的标题和结构化的回答，使用列表、代码块、表格等增强可读性。同时，按照用户之前的格式要求，数学公式用$...$，独立公式用$$...$$，但根据当前问题内容，可能数学公式较少，更多是技术描述。 需要验证引用内容是否准确，比如缓存雪崩的解决方案，均匀设置过期时间，结合固定值和随机值。同时，Redis多线程的部分，要确认6.0版本后的多线程仅用于网络IO，命令处理还是单线程，避免错误信息。 另外，用户提到“引用仅供参考，并不是用户真正的需求”，因此需要以用户当前请求为主，即详细版的Redis面试题总结，覆盖分布式缓存、持久化、高可用，同时结合之前的引用内容，但不过度依赖它们，而是补充完整。 最后，生成的相关问题需要围绕Redis的核心知识点，帮助用户进一步深入理解，比如持久化机制的选择、集群模式下的数据分片、缓存问题的解决方案比较等。 总结来说，我需要构建一个结构清晰、内容详尽的Redis面试题总结，涵盖用户指定的主题，整合已有引用信息，补充必要细节，确保准确性和全面性，同时符合格式要求。</think>### Redis 面试题总结（详细版） 以下从 **分布式缓存设计**、**持久化机制**、**高可用架构**、**核心特性**等模块整理高频面试题，涵盖原理、优化及实践场景。 --- #### 一、分布式缓存核心问题与解决方案 1. **缓存雪崩** - **定义**：大量缓存数据**同时过期**或 **Redis 宕机**，导致请求直接穿透到数据库，引发数据库压力过大甚至崩溃。 - **解决方案**： - **均匀过期时间**：设置基础过期时间（如 $T$）叠加随机值（如 $T + \text{rand}(0, 1800)$ 秒）[^1]。 - **高可用集群**：部署 Redis 主从集群或哨兵模式，避免单点故障。 - **熔断降级**：通过 Hystrix 等工具在数据库压力过大时触发限流。 2. **缓存击穿** - **定义**：某个**热点 Key** 过期后，高并发请求瞬间穿透到数据库。 - **解决方案**： - **互斥锁**：使用 Redis 的 `SETNX` 命令实现分布式锁，保证只有一个线程重建缓存。 - **逻辑过期**：缓存永不过期，业务代码异步更新数据并重置逻辑过期时间。 3. **缓存穿透** - **定义**：查询**不存在的数据**（如非法 ID），绕过缓存直接访问数据库。 - **解决方案**： - **布隆过滤器**：预存所有合法 Key 的哈希值，拦截非法请求。 - **空值缓存**：对查询结果为空的 Key 缓存短期空值（如 5 分钟）。 --- #### 二、持久化机制 1. **RDB (Redis Database)** - **原理**：生成内存数据的**快照**文件（默认 `dump.rdb`），通过 `SAVE`（阻塞）或 `BGSAVE`（后台异步）触发。 - **优点**：文件紧凑，恢复速度快。 - **缺点**：可能丢失最后一次快照后的数据。 - **配置命令**： ```bash save 900 1 # 900秒内至少1次修改触发快照 save 300 10 ``` 2. **AOF (Append Only File)** - **原理**：记录所有**写操作命令**（如 `SET`、`DEL`），通过重放命令恢复数据。 - **优点**：数据丢失风险低（支持每秒同步）。 - **缺点**：文件体积大，恢复速度慢。 - **刷盘策略**： - `appendfsync always`：每次写操作同步（安全，性能低）。 - `appendfsync everysec`：每秒同步（平衡）。 - `appendfsync no`：由操作系统决定（性能高，风险大）。 3. **混合持久化（Redis 4.0+）** - **原理**：结合 RDB 和 AOF，**AOF 文件包含 RDB 头部 + 增量 AOF 命令**。 - **优势**：快速加载 RDB 快照，同时保留增量数据安全性。 - **启用方式**： ```bash aof-use-rdb-preamble yes ``` --- #### 三、高可用架构 1. **主从复制** - **原理**：主节点（Master）异步复制数据到从节点（Slave）。 - **优点**：读写分离（写主读从），提升读性能。 - **缺点**：主节点宕机需手动切换。 - **搭建命令**： ```bash # 在从节点执行 REPLICAOF 127.0.0.1 6379 ``` 2. **哨兵模式（Sentinel）** - **功能**：监控主节点健康状态，自动故障转移（选举新 Master）。 - **部署要求**：至少 3 个 Sentinel 实例避免脑裂。 - **配置示例**： ```bash sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 5000 ``` 3. **Cluster 集群模式** - **原理**：数据分片（**16384 个槽**），每个节点负责部分槽位，支持自动扩缩容。 - **优点**：去中心化，高可用与高性能兼备。 - **节点通信**：使用 **Gossip 协议**交换状态信息。 - **命令示例**： ```bash redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 ... ``` --- #### 四、Redis 核心特性与优化 1. **线程模型** - **Redis 6.0 前**：单线程处理命令（避免锁竞争，保证原子性）。 - **Redis 6.0+**：**多线程网络 IO**（提升吞吐量），但**命令执行仍为单线程**。 - **性能瓶颈**：网络带宽和内存速度，而非 CPU[^3][^4]。 2. **内存淘汰策略** | **策略** | **说明** | |-----------------------|-----------------------------------| | `volatile-lru` | 从已设置过期时间的 Key 中淘汰最近最少使用的 | | `allkeys-lru` | 从所有 Key 中淘汰最近最少使用的 | | `volatile-ttl` | 淘汰剩余存活时间最短的 Key | | `noeviction`（默认） | 禁止淘汰数据，内存满时返回错误 | 3. **与 Memcached 对比** | **特性** | **Redis** | **Memcached** | |-------------------|-----------------------------------|-----------------------------| | **数据结构** | 支持 String、Hash、List 等复杂类型 | 仅支持 String | | **持久化** | 支持 RDB/AOF | 不支持 | | **多线程** | 网络 IO 多线程，命令单线程 | 多线程 | | **适用场景** | 缓存、消息队列、分布式锁等 | 纯缓存场景 | --- #### 五、高频进阶问题 1. **如何保证 Redis 与数据库的数据一致性？** - **方案**：延迟双删（先删缓存→更新数据库→休眠→再删缓存）、订阅数据库 Binlog 异步更新缓存。 2. **Redis 如何实现分布式锁？** - **核心命令**：`SET key value NX PX 30000`（原子操作）。 - **Redisson 优化**：Watch Dog 自动续期、可重入锁、Lua 脚本原子操作[^1]。 3. **Pipeline 和事务的区别？** - **Pipeline**：批量发送命令，减少网络往返时间（无原子性保证）。 - **事务**：通过 `MULTI/EXEC` 包裹命令，保证原子性（但无回滚）。 --- ### 相关问题 1. **Redis 集群模式下如何实现跨槽位命令（如 MGET）？** 2. **AOF 重写过程中宕机，如何保证数据完整性？** 3. **Redis 的 Hash 扩容过程是怎样的？** 4. **如何通过 Redis 实现延迟队列？** [^1]: Redis 高可用架构设计与实践 [^3]: Redis 6.0 多线程模型解析 [^4]: Redis 与 Memcached 性能对比分析
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值