redis 集群

于 2024-05-07 10:01:18 发布
阅读量1.1k 收藏 12
点赞数 10
分类专栏： reids 文章标签： redis 数据库 缓存
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_45726327/article/details/138470090
版权

文章目录

前言

我们先提出几个问题？

  1. 如果现在一个机器数据量很大，一句超出了物理内存的极限，该怎么办？
  2. 如何对存储的数据进行管理？
  3. 如何构建集群？
  4. 如果集群出现故障怎么办？
  5. 集群如果要扩充新内容，该怎么办？

我们将围绕这几个问题进行解答。

集群的概念

如何获取更⼤的空间? 加机器即可! 所谓 “⼤数据” 的核⼼, 其实就是⼀台机器搞不定了, ⽤多台机器来
搞。
Redis 的集群就是在上述的思路之下, 引⼊多组 Master / Slave , 每⼀组 Master / Slave 存储数据全集的⼀部分, 从⽽构成⼀个更⼤的整体, 称为 Redis 集群 (Cluster).
假定整个数据全集是 1 TB, 引⼊三组 Master / Slave 来存储. 那么每⼀组机器只需要存储整个
数据全集的 1/3 即可.

在这里插入图片描述

Master1 和 Slave11 和 Slave12 保存的是同样的数据. 占总数据的 1/3
Master2 和 Slave21 和 Slave22 保存的是同样的数据. 占总数据的 1/3
Master3 和 Slave31 和 Slave32 保存的是同样的数据. 占总数据的 1/3
这三组机器存储的数据都是不同的.
每个 Slave 都是对应 Master 的备份(当 Master 挂了, 对应的 Slave 会补位成 Master).
每个红框部分都可以称为是⼀个 分⽚ (Sharding).
如果全量数据进⼀步增加, 只要再增加更多的分⽚, 即可解决.

数据分片算法

Redis cluster 的核⼼思路是⽤多组机器来存数据的每个部分. 那么接下来的核⼼问题就是, 给定⼀个数据 (⼀个具体的 key), 那么这个数据应该存储在哪个分⽚上? 读取的时候⼜应该去哪个分⽚读取?
接下来，我们来看看。

1.hash 求余

算法原理

Hash 求余是一种常用的数据分布策略，通常用于将数据均匀分配到多个存储节点。算法的基本思想是使用哈希函数对数据项的键值进行哈希处理，然后取结果的模（即余数），用来决定将数据存储在哪个节点。例如，如果有 N 个节点，可以将哈希值除以 N 并取余数，得到的余数范围在 0 到 N-1 之间，这个余数就代表数据应当存储在哪个节点。
具体的算法发区如下图所示:
在这里插入图片描述

存在问题

扩缩容问题：当增加或减少节点时，大部分键值的映射关系会发生改变，需要重新分配，这就引发了大量的数据迁移，对系统的稳定性和性能产生影响。
负载不均衡：如果数据分布不均匀或节点性能各异，简单的 hash 求余可能导致某些节点负载过高，而其他节点则相对空闲。

2.一致性hash算法

算法原理

一致性哈希算法是为了解决简单哈希求余中节点增减引起的大量数据迁移问题而提出的。它将整个哈希值空间组织成一个虚拟的圆环，例如使用 0 到 2^32-1 的哈希空间。每个节点在这个环上占据一个哈希值的位置，每个数据项的键也通过哈希函数映射到这个环上的某个点。数据存储在顺时针遇到的第一个节点上。当增加或删除节点时，只有该节点附近的数据需要重新定位，从而大大减少了迁移的数据量。

  • 第⼀步, 把 0 -> 2^32-1 这个数据空间, 映射到⼀个圆环上. 数据按照顺时针⽅向增⻓
    在这里插入图片描述

  • 第⼆步, 假设当前存在三个分⽚, 就把分⽚放到圆环的某个位置上
    在这里插入图片描述

  • 第三步:假定有⼀个 key, 计算得到 hash 值 H, 那么这个 key 映射到哪个分⽚呢? 规则很简单, 就是从 H所在位置, 顺时针往下找, 找到的第⼀个分⽚, 即为该 key 所从属的分⽚.
    在这里插入图片描述

存在问题

  • 数据倾斜问题：如果节点较少，或者哈希函数的映射不够均匀，仍然可能出现数据分布不均的问题。
  • 环的管理：随着节点的频繁增减，环的管理和数据的重新定位可能会变得复杂。

3.哈希槽分区算法 (Redis 使用)

算法原理

Redis 的集群使用了一种称为 “哈希槽” 的技术来分配和管理键空间。在 Redis 集群中，存在 16384 个哈希槽，每个键通过哈希函数被映射到这 16384 个槽中的一个。每个集群节点负责一部分哈希槽，例如在一个三个节点的集群中，每个节点可能负责大约 5461 个槽。当需要查找一个键时，先计算这个键的哈希槽，然后直接转到负责该槽的节点。

Redis Cluser采用虚拟槽分区，所有的键根据哈希函数映射到0~16383整
数槽内，计算公式：slot=CRC16（key）&16383。每一个节点负责维护一部
分槽以及槽所映射的键值数据.
在这里插入图片描述

使用CRC16（key）&16383将键映射到槽上
在这里插入图片描述

搭建环境集群环境

拓扑结构图

在这里插入图片描述
此处我们先创建出 11 个 redis 节点. 其中前 9 个⽤来演⽰集群的搭建.
后两个⽤来演⽰集群扩容.

创建目录和配置

[root@VM-16-7-centos redis]# mkdir redis-cluster
[root@VM-16-7-centos redis]# cd redis-cluster/
[root@VM-16-7-centos redis-cluster]# ls
[root@VM-16-7-centos redis-cluster]# touch docker-compose.yml
[root@VM-16-7-centos redis-cluster]# touch generate.sh

补充docker-compose和generate.sh 文件

generate.sh

for port in $(seq 1 9); \
do \
mkdir -p redis${port}/
touch redis${port}/redis.conf
cat << EOF > redis${port}/redis.conf
port 6379
bind 0.0.0.0
protected-mode no
appendonly yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 172.30.0.10${port}
cluster-announce-port 6379
cluster-announce-bus-port 16379
EOF
done
# 注意 cluster-announce-ip 的值有变化. 
for port in $(seq 10 11); \
do \
mkdir -p redis${port}/
touch redis${port}/redis.conf
cat << EOF > redis${port}/redis.conf
port 6379
bind 0.0.0.0
protected-mode no
appendonly yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 172.30.0.1${port}
cluster-announce-port 6379
cluster-announce-bus-port 16379
EOF
done

docker-compose.yml

version: '3.7'
networks:
  mynet:
    ipam:
      config:
        - subnet: 172.30.0.0/24
services:
  redis1:
    image: 'redis:5.0.9'
    container_name: redis1
    restart: always
    volumes:
      - ./redis1/:/etc/redis/
    ports:
      - 6371:6379
      - 16371:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.101
  redis2:
    image: 'redis:5.0.9'
    container_name: redis2
    restart: always
    volumes:
      - ./redis2/:/etc/redis/
    ports:
      - 6372:6379
      - 16372:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.102
  redis3:
    image: 'redis:5.0.9'
    container_name: redis3
    restart: always
    volumes:
      - ./redis3/:/etc/redis/
    ports:
      - 6373:6379
      - 16373:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.103
  redis4:
    image: 'redis:5.0.9'
    container_name: redis4
    restart: always
    volumes:
      - ./redis4/:/etc/redis/
    ports:
      - 6374:6379
      - 16374:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.104
  redis5:
    image: 'redis:5.0.9'
    container_name: redis5
    restart: always
    volumes:
      - ./redis5/:/etc/redis/
    ports:
      - 6375:6379
      - 16375:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.105
  redis6:
    image: 'redis:5.0.9'
    container_name: redis6
    restart: always
    volumes:
      - ./redis6/:/etc/redis/
    ports:
      - 6376:6379
      - 16376:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.106
  redis7:
    image: 'redis:5.0.9'
    container_name: redis7
    restart: always
    volumes:
      - ./redis7/:/etc/redis/
    ports:
      - 6377:6379
      - 16377:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.107
  redis8:
    image: 'redis:5.0.9'
    container_name: redis8
    restart: always
    volumes:
      - ./redis8/:/etc/redis/
    ports:
      - 6378:6379
      - 16378:16379
    command: redis-server /etc/redis/redis.conf
    networks:
        mynet:
          ipv5_address: 172.30.0.108
  redis9:
    image: 'redis:5.0.9'
    container_name: redis9
    restart: always
    volumes:
      - ./redis9/:/etc/redis/
    ports:
      - 6379:6379
      - 16379:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.109
  redis10:
    image: 'redis:5.0.9'
    container_name: redis10
    restart: always
    volumes:
      - ./redis10/:/etc/redis/
    ports:
      - 6380:6379
      - 16380:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.110
  redis11:
    image: 'redis:5.0.9'
    container_name: redis11
    restart: always
    volumes:
      - ./redis11/:/etc/redis/
    ports:
      - 6381:6379
      - 16381:16379
    command: redis-server /etc/redis/redis.conf
    networks:
      mynet:
        ipv4_address: 172.30.0.111

启动容器

docker-compose up -d

在这里插入图片描述

把上述的redis节点构建成集群

redis-cli --cluster create 172.30.0.101:6379 172.30.0.102:6379 
172.30.0.103:6379 172.30.0.104:6379 172.30.0.105:6379 172.30.0.106:6379 172.30.0.107:6379 172.30.0.108:6379 172.30.0.109:6379 --cluster-replicas 2
  • –cluster create 表⽰建⽴集群. 后⾯填写每个节点的 ip 和地址.
  • –cluster-replicas 2 表示 每个主节点需要两个从节点备份.
    执行之后, 容器之间会进⾏加入集群操作

在这里插入图片描述

使用集群

使用cluster nodes 查看集群信息
在这里插入图片描述

假设主节点宕机

查看当前节点。
在这里插入图片描述

⼿动停⽌⼀个 master 节点, 观察效果.

docker stop redis1

在这里插入图片描述
重新启动redis1，再来看看效果。

doker start redis1

在这里插入图片描述

故障转移的具体处理流程

故障判定

集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态。具体的过程如图所示：
在这里插入图片描述

  1. 节点 A 给 节点 B 发送 ping 包, B 就会给 A 返回⼀个 pong 包. ping 和 pong 除了 message type属性之外, 其他部分都是⼀样的. 这⾥包含了集群的配置信息(该节点的id, 该节点从属于哪个分⽚,是主节点还是从节点, 从属于谁, 持有哪些 slots 的位图…).
  2. 每个节点, 每秒钟, 都会给⼀些随机的节点发起 ping 包, ⽽不是全发⼀遍. 这样设定是为了避免在节点很多的时候, ⼼跳包也⾮常多(⽐如有 9 个节点, 如果全发, 就是 9 * 8 有 72 组⼼跳了, ⽽且这是按照 N^2 这样的级别增⻓的).
  3. 当节点 A 给节点 B 发起 ping 包, B 不能如期回应的时候, 此时 A 就会尝试重置和 B 的 tcp 连接, 看能否连接成功. 如果仍然连接失败, A 就会把 B 设为 PFAIL 状态(相当于主观下线).
  4. A 判定 B 为 PFAIL 之后, 会通过 redis 内置的 Gossip 协议, 和其他节点进⾏沟通, 向其他节点确认 B的状态. (每个节点都会维护⼀个⾃⼰的 “下线列表”, 由于视⻆不同, 每个节点的下线列表也不⼀定相同).
  5. 此时 A 发现其他很多节点, 也认为 B 为 PFAIL, 并且数⽬超过总集群个数的⼀半, 那么 A 就会把 B 标记成 FAIL (相当于客观下线), 并且把这个消息同步给其他节点(其他节点收到之后, 也会把 B 标记成FAIL).
    ⾄此, B 就彻底被判定为故障节点了。

故障迁移

所谓故障迁移就是保证集群的可用性，如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它，从而保证集群的高可用。下线主节点的所有从节点承担故障恢复的义务，当从节点通过内部定时任务发现自身复制的主节点进入客观下线时，将会触发故障恢复流程。
故障恢复流程如下：
在这里插入图片描述

  1. 从节点判定⾃⼰是否具有参选资格. 如果从节点和主节点已经太久没通信(此时认为从节点的数据和主节点差异太⼤了), 时间超过阈值, 就失去竞选资格.
  2. 具有资格的节点, ⽐如 C 和 D, 就会先休眠⼀定时间. 休眠时间 = 500ms 基础时间 + [0, 500ms] 随机
    时间 + 排名 * 1000ms. offset 的值越⼤, 则排名越靠前(越⼩).
  3. ⽐如 C 的休眠时间到了, C 就会给其他所有集群中的节点, 进⾏拉票操作. 但是只有主节点才有投票资格.
  4. 主节点就会把⾃⼰的票投给 C (每个主节点只有 1 票). 当 C 收到的票数超过主节点数⽬的⼀半, C 就会晋升成主节点. (C ⾃⼰负责执⾏ slaveof no one, 并且让 D 执⾏ slaveof C).
  5. 同时, C 还会把⾃⼰成为主节点的消息, 同步给其他集群的节点. ⼤家也都会更新⾃⼰保存的集群结构信息.

集群扩容

上⾯已经把 redis1 - redis9 重新构成了集群. 接下来把 redis10 和 redis11 也加⼊集群.
这里我们以110为master，111 为slave ，相当于把数据分片从3->4.

  1. 将新的节点110 加入集群中
 redis-cli --cluster add-node 172.30.0.110:6379 172.30.0.101:6379

add-node 后的第⼀组地址是新节点的地址. 第⼆组地址是集群中的任意节点地址.
在这里插入图片描述

  1. 重新分配 slots
redis-cli --cluster reshard 172.30.0.101:6379

执行命令以后，你会遇到的操作。
在这里插入图片描述
这时候会让你输入分片内容

在这里插入图片描述

在这里插入图片描述

  1. 给新的主节点添加从节点
redis-cli --cluster add-node 172.30.0.111:6379 172.30.0.101:6379 --cluster-slave --cluster-master-id 7c2a7cd67ee35561280e0be8ddf2c50ae64b01e0

进入redis一个节点，查看集群状态，这个时候就能看到110的节点就有分片。
在这里插入图片描述

忘忧记
关注
  • 10
    点赞
  • 踩
  • 12
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Redis集群配置文件
12-27
Redis集群配置文件，包含了三个主节点，三个从节点的配置文件，该配置是在docker中运行，有完整的docker-compose.yml文件，只要修改映射的宿主机的路径为你自己的路径。然后直接docker-compose up既可以完成环境启动...
k8s集群搭建redis集群
09-22
k8s集群搭建redis集群 k8s集群搭建redis集群 k8s集群搭建redis集群 k8s集群搭建redis集群 k8s集群搭建redis集群
Redis---集群
flyingcloud6的博客
06-22 8266
对于redis的集群进行了讲解。
Redis数据库搭建集群（集群概念、redis集群介绍、搭建集群操作、Python与redis集群交互）
IT之一小佬的博客
02-16 7158
Redis数据库搭建集群（集群概念、redis集群介绍、搭建集群操作、Python与redis集群交互）
15.集群知识（MySQL+Redis+ElasticSearch+RabbitMQ）
onlySunKim的博客
06-19 962
高可用：主机宕机对业务无影响。宕机原因：网卡、路由器、机房、CPU负载过高、内存溢出、自然灾害等不可预期的原因导致，也称单点问题解决方案：【选主式（双主、raft选举）】重新创建主节点单点性能限制：当单点数据量过大导致性能降低，所以需要多台分担共同存储整个集群数据，并且做好互相备份保证即使单点故障，也能在其他节点找到数据解决方案：【分片式（分库分表）】数据备份容灾：单点故障后，存储的数据仍然可以在别的地方拉起解决方案：【主从复制】
Redis集群原理详解
热门推荐
张维鹏的博客
02-16 5万+
一、redis cluster 介绍： 1、单实例的Redis架构： 最开始的一主N从加上读写分离，Redis作为缓存单实例貌似也还不错，并且有Sentinel哨兵机制，可以实现主从故障迁移。 单实例Redis本质上只有一台Master作为存储，就算机器为128GB的内存，一般建议使用率也不要超过70%-80%，所以最多使用100GB数据就已经很多了，实际中50%就不错了，因为数据量太大也会降低服务的稳定性，而且数据量太大意味着持久化成本高，可能严重阻塞服务，甚至最终切主。所以，单实例还存在以下几
Redis集群详解
怪咖@的博客
06-26 1万+
在了解Redis集群之前尽量先了解清楚Redis的主从复制和哨兵机制。读写分离，性能扩展，降低主服务器的压力容灾，快速恢复，主机挂掉时，从机变为主机Redis 主从模式不具备自动容错和恢复功能，如果主节点宕机，Redis 集群将无法工作，此时需要人为干预，将从节点提升为主节点。哨兵机制作用主要是监控主从节点，当主节点挂掉，通过内部投票机制，从 从节点当中选出一个主节点，这样可以避免人工成本。虽然主从+哨兵采用了多节点，但是他们存在的目的主要是解决容灾问题，而并非性能问题。
redis集群批量插入
11-23
java连接redis集群批量String类型插入
Redis集群数据迁移操作文档
06-29
1、新旧redis集群迁移 2、支持redis集群的存量和增量数据迁移 3、支持redis集群数据的离线迁移
Redis集群测试
08-16
Redis集群测试
redis的集群方案和常见问题
m0_37742400的博客
02-04 1231
本文讲解了redis集群的三种方式的常见问题和基本解决方案，包括主从集群，哨兵模式，分片集群方式
Redis集群教程
陈自选的博客
07-01 787
一、集群简介 本文章简要地介绍了Redis集群，它不使用特别深入地来理解分布式系统的概念。 它提供了关于如何设置集群、测试和操作它的说明，而不涉及Redis集群规范中涉及的细节，只是从用户的角度描述了系统的行为。 然而，本教程试图从最终用户的角度提供关于Redis集群可用性和一致性特征的信息，以一种简单易懂的方式进行说明。 注意：本教程要求R...
【技术选型】Redis的几种集群方案、及优缺点对比
DreamSun的博客
06-26 964
客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集。在服务开发中，单机都会存在单点故障的问题，及服务部署在一台服务器上，一旦服务器宕机服务就不可用，所以为了让服务高可用，分布式服务就出现了，将同一服务部署到多台机器上，即使其中几台服务器宕机，只要有一台服务器可用服务就可用。
Redis的集群方案
m0_70386582的博客
09-25 1081
Redis的集群方案
Redis学习+集群搭建+持久化+主从复制（详细学习）_windows7 redis集群搭建
最新发布
2301_77033340的博客
05-02 548
在集群模式下,Redis接受任何键相关命令时首先会计算键对应的槽,再根据槽找出所对应的节点如果节点是自身,则处理键命令;否则回复MOVED重定向错误,通知客户端请求正确的节点,这个过程称为Mover重定向.知道了ask路由后,我们使用-c选项批量插入一些数据。
redis cluster集群常见错误问题记录
月光秦城
05-31 3621
redis cluster集群常见问题记录
Redis Cluster集群运维与核心原理剖析【收获满满】
沮丧的南瓜
07-01 321
一、Redis集群方案比较 1、哨兵模式 在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master。 哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率高。 2、高可用集群模式 redis集
Redis Cluster集群的搭建与测试
moneywenxue的博客
10-30 940
一、前言 redis最初使用主从模式作集群，但是这种模式master宕机后需要手动配置将slave转成master；后来为了高可用，提出了哨兵模式，该模式有哨兵角色监视master和slave，若master宕机，可以自动将slave转换成master，但哨兵模式也有不足：1.不能动态扩充；2.仍然不能支持并发量特别大的场景。所以redis3.x提出来了cluster集群模式。 二、redis-cluster设计 Redis-Cluster采用无中心结构，每个节点报存数据和集群状态，每个节点和其他节点
Redis(五)集群化方案对比：Codis、Twemproxy、Redis Cluster
qq_23435961的博客
07-28 516
Redis(五)集群化方案对比：Codis、Twemproxy、Redis Cluster 之前我们提到，为了保证Redis的高可用，主要需要以下几个方面： 数据持久化 主从复制 自动故障恢复 集群化 我们简单理一下这几个方案的特点，以及它们之间的联系。 数据持久化本质上是为了做数据备份，有了数据持久化，当Redis宕机时，我们可以把数据从磁盘上恢复回来，但在数据恢复之前，服务是不可用的，而且数据恢复的时间取决于实例的大小，数据量越大，恢复起来越慢。Redis的持久化过程可以参考Redis (一)–持久
celery redis集群
03-28
Celery是一个Python分布式任务队列框架，而Redis是一个高性能的键值存储数据库。当它们结合在一起时，可以构建一个强大的分布式任务队列系统。 Celery和Redis集群的结合可以提供以下功能： 1. 异步任务处理：Celery可以将任务异步地发送到Redis集群中，然后由工作节点处理。这样可以避免任务阻塞主线程，提高系统的响应速度。 2. 分布式任务调度：Redis集群可以作为Celery的消息代理，负责存储和传递任务消息。多个Celery工作节点可以从Redis集群中获取任务，并进行并行处理。 3. 任务结果存储：Celery可以将任务的执行结果存储在Redis集群中，以便后续查询和使用。 4. 任务队列监控：Redis集群可以提供监控和管理Celery任务队列的功能，例如查看队列长度、清理过期任务等。 为了搭建Celery和Redis集群，你需要进行以下步骤： 1. 安装和配置Redis集群：根据你的需求，可以选择使用Redis Sentinel或Redis Cluster来搭建Redis集群。配置好集群后，确保所有节点都正常运行。 2. 安装和配置Celery：使用pip安装Celery库，并在Celery配置文件中指定Redis集群的连接信息。 3. 编写任务代码：定义你的任务函数，并使用Celery的装饰器将其注册为Celery任务。 4. 启动Celery工作节点：在每个工作节点上启动Celery的工作进程，它们将从Redis集群中获取任务并执行。 5. 发布和调度任务：在你的应用程序中，使用Celery的API将任务发布到Redis集群中，并设置任务的调度规则。

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

忘忧记

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值