redis 集群 failover 源码分析

最新推荐文章于 2022-07-04 23:10:38 发布
最新推荐文章于 2022-07-04 23:10:38 发布
阅读量493 收藏
点赞数 1
分类专栏： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_31720329/article/details/104068469
版权
本文深入探讨Redis集群的failover过程，包括PFAIL、FAIL状态的转变，以及ELECT阶段的主节点选举机制。文章指出，在节点失效后，通过gossip协议传播节点状态，当多数节点确认某节点失效后，将触发主节点选举，确保集群的高可用性。
摘要由CSDN通过智能技术生成

failover

以后都在 github 更新，请戳 redis 集群->failover

contents

需要提前了解的知识

prerequisites->cluster 中展示了示例集群的配置

如果我们增加一个新的节点 127.0.0.1:7003

127.0.0.1:7003> CLUSTER MEET 127.0.0.1 7000
OK
127.0.0.1:7003> CLUSTER NODES
75ddecf9169096eeff03ec60f868859333c824a1 127.0.0.1:7003@17003 myself,master - 0 1579513065000 0 connected
ba060347b647e2cb050eea666f087fd08d4e42d7 127.0.0.1:7001@17001 master - 0 1579513065256 2 connected 5461-10922
c62cfa7c26ec449462cceb5fd45cac121d866d44 127.0.0.1:7002@17002 master - 0 1579513066283 3 connected 10923-16383
89c21152eedde6d9dec2fcebf4330b39810bc179 127.0.0.1:7000@17000 master - 0 1579513066797 1 connected 0-5460
127.0.0.1:7003> CLUSTER REPLICATE 89c21152eedde6d9dec2fcebf4330b39810bc179

并把它设置为节点 127.0.0.1:7000 的从节点

127.0.0.1:7003> CLUSTER REPLICATE 89c21152eedde6d9dec2fcebf4330b39810bc179
OK
127.0.0.1:7003> CLUSTER NODES
75ddecf9169096eeff03ec60f868859333c824a1 127.0.0.1:7003@17003 myself,slave 89c21152eedde6d9dec2fcebf4330b39810bc179 0 1579513200000 0 connected
ba060347b647e2cb050eea666f087fd08d4e42d7 127.0.0.1:7001@17001 master - 0 1579513201517 2 connected 5461-10922
c62cfa7c26ec449462cceb5fd45cac121d866d44 127.0.0.1:7002@17002 master - 0 1579513201000 3 connected 10923-16383
89c21152eedde6d9dec2fcebf4330b39810bc179 127.0.0.1:7000@17000 master - 0 1579513201833 1 connected 0-5460

并且让节点 127.0.0.1:7000 宕机

^C943:signal-handler (1579016631) Received SIGINT scheduling shutdown...
943:M 14 Jan 2020 23:43:51.330 # User requested shutdown...
943:M 14 Jan 2020 23:43:51.330 * Calling fsync() on the AOF file.
943:M 14 Jan 2020 23:43:51.330 # Redis is now ready to exit, bye bye...
zpoint@bogon 7000 %

我们可以发现节点 127.0.0.1:7003 变成了主节点并且该节点的 epoch 值成了集群中最大的值

127.0.0.1:7003> CLUSTER NODES
ba060347b647e2cb050eea666f087fd08d4e42d7 127.0.0.1:7001@17001 master - 0 1579572427408 2 connected 5461-10922
89c21152eedde6d9dec2fcebf4330b39810bc179 127.0.0.1:7000@17000 master,fail - 1579572351865 1579572351452 5 disconnected
75ddecf9169096eeff03ec60f868859333c824a1 127.0.0.1:7003@17003 myself,master - 0 1579572426000 7 connected 0-5460
c62cfa7c26ec449462cceb5fd45cac121d866d44 127.0.0.1:7002@17002 master - 0 1579572426898 3 connected 10923-16383

PFAIL

我们让节点 127.0.0.1:7000 宕机时发生了什么 ?

overview

对于 master/7001, master/7002 还有 slave/7003, clusterCron 会在超过 cluster-node-timeout 毫秒后还无法接收到 PONG 消息的节点标记成 PFAIL, 默认值为 15 秒

  /* 计算 PONG 的延时, 注意如果我们已经收到了 PONG 消息, 则 node->ping_sent 会被置为 0, 所以代码进不到这里 */
    delay = now - node->ping_sent;

if (delay > server.cluster_node_timeout) {
    /* 达到超时条件, 如果这个节点不在 PFAIL 状态, 则把这个节点置于 PFAIL 状态 */
    if (!(node->flags & (CLUSTER_NODE_PFAIL|CLUSTER_NODE_FAIL))) {
        serverLog(LL_DEBUG,"*** NODE %.40s possibly failing",
            node->name);
        node->flags |= CLUSTER_NODE_PFAIL;
        update_state = 1;
    }
}

pfail
master/7001, master/7002 和 slave/7003 会通过 gossip 协议进行交流, 在 cluster-node-timeout 毫秒之后还收不到某个节点的 PONG 消息时, 就会把这个节点置于 PFAIL` 状态

pfail2
每一个节点都有自己的 cluster-node-timeout 配置, 并且每个节点发送 PING 消息的时刻都不相同, 但如果节点 master/7000 真的宕机了, 在不同节点的 PING 时刻 + cluster-node-timeout 毫秒之后, 大部分的正常节点都会把 master/7000 标记为 PFAIL 状态

FAIL

master/7000 的 PFAIL 状态会通过 gossip 协议传播, 每当一个节点通过该协议接收到集群中的一个节点处于 PFAIL 状态时, markNodeAsFailingIfNeeded 这个函数就会被调用

markNodeAsFailingIfNeeded 会在至少有 (server.cluster->size / 2) + 1 个节点把对应节点标记成 PFAIL 状态时就把这个节点直接置为 FAIL 状态, 既在当前集群收到 2 个关于 节点 master/7000 的 PFAIL 状态, 就把这个节点设置为 FAIL 状态

void markNodeAsFailingIfNeeded(clusterNode *node) {
    int failures;
    int needed_quorum = (server.cluster->size / 2) + 1;

    if (!nodeTimedOut(node)) return; /* 我自己能和目标节点收发消息 */
    if (nodeFailed(node)) return; /* 这个节点已经被标记成 FAIL 了 */

    failures = clusterNodeFailureReportsCount(node);
    /* 如果我自己也是 master, 那么把我自己也计入数目中 */
    if (nodeIsMaster(myself)) failures++;
    if (failures < needed_quorum) return; /* 把目标节点标记成 PFAIL 的 master 节点还不集群数目的一半, 不操作 */

    serverLog(LL_NOTICE,
        "Marking node %.40s as failing (quorum reached).", node->name);

    /* 把目标节点标记成 FAIL */
    node->flags &= ~CLUSTER_NODE_PFAIL;
    node->flags |= CLUSTER_NODE_FAIL;
    node->fail_time = mstime();

    /* 把目标节点被标记成 FAIL 这个信息广播给集群里的所有其他节点,
     * 让所有能与我自己建立连接的节点都把目标节点标记成 FAIL */
    if (nodeIsMaster(myself)) clusterSendFail(node->name);
    clusterDoBeforeSleep(CLUSTER_TODO_UPDATE_STATE|CLUSTER_TODO_SAVE_CONFIG);
}

如果 master/7001 是第一个发现 master/7000 有 2 个 PFAIL 状态的话, 它会把它标记成 FAIL 状态并在集群中广播该条状态信息

fail

ELECT

只要一个节点获得了 master/7000 的 2 个 PFAIL 状态, 那么这个节点就会把 master/7000 标记为 FAIL

只有槽数大于 1 的 master 节点的 PFAIL 算数

elect

并且把这个节点的 FAIL 状态广播给集群中所有的节点

elect2
每一个 slave 在每一次 clusterCron 循环中都会调用 clusterHandleSlaveFailover 这个函数

void clusterHandleSlaveFailover(void) {
    mstime_t data_age;
    mstime_t auth_age = mstime() - server.cluster->failover_auth_time;
    int needed_quorum = (server.cluster->size / 2) + 1;
    int manual_failover = server.cluster->mf_end != 0 &&
                          server.cluster->mf_can_start;
    mstime_t auth_timeout, auth_retry_time;

    server.cluster->todo_before_sleep &= ~CLUSTER_TODO_HANDLE_FAILOVER;

    /* 计算 failover 超时 (发送投票消息和等待响应的最大时间)
     * 和 failover 的重试时间 (再次发起投票请求的时间)
     * 超时是 MAX(NODE_TIMEOUT*2,2000) 毫秒
     * 重试时间是 上面的超时 * 2
     */
    auth_timeout = server.cluster_node_timeout*2;
    if (auth_timeout < 2000) auth_timeout = 2000;
    auth_retry_time = auth_timeout*2;

    /* 不论是手动的 failover 还是自动的 failover
     * 运行该函数需要满足下面所有的先决条件
     * 1) 我自己本身是 slave
     * 2) 我的 master 已经被标记成 FAIL 状态, 或者这次是一个手动的 failover
     * 3) 设置里没有配置不允许 failover 的选项, 并且本次不是一个手动的 failover
     * 4）当前节点没有服务任何一个槽
    if (nodeIsMaster(myself) ||
        myself->slaveof == NULL ||
        (!nodeFailed(myself->slaveof) && !manual_failover) ||
        (server.cluster_slave_no_failover && !manual_failover) ||
        myself->slaveof->numslots == 0)
    {
        /* 没有必要进行 failover, 我们设置了为什么不能进行 failover 的原因并返回 */
        server.cluster->cant_failover_reason = CLUSTER_CANT_FAILOVER_NONE;
        return;
    }
    /* ... */
    /* 必要的时候发起新的一轮投票 */
    if (server.cluster->failover_auth_sent == 0) {
        server.cluster->currentEpoch++;
        server.cluster->failover_auth_epoch = server.cluster->currentEpoch;
        serverLog(LL_WARNING,"Starting a failover election for epoch %llu.",
            (unsigned long long) server.cluster->currentEpoch);
        clusterRequestFailoverAuth();
        server.cluster->failover_auth_sent = 1;
        clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG|
                             CLUSTER_TODO_UPDATE_STATE|
                             CLUSTER_TODO_FSYNC_CONFIG);
        return; /* 等待回复 */
    }

    /* 查看是否有法定的投票数投了我 */
    if (server.cluster->failover_auth_count >= needed_quorum) {
        /* 我们有达到执行的票数, 可以进行 failover */

        serverLog(LL_WARNING,
            "Failover election won: I'm the new master.");

        /* 把自己的 configEpoch 设置为选举的 epoch */
        if (myself->configEpoch < server.cluster->failover_auth_epoch) {
            myself->configEpoch = server.cluster->failover_auth_epoch;
            serverLog(LL_WARNING,
                "configEpoch set to %llu after successful failover",
                (unsigned long long) myself->configEpoch);
        }

        /* 执行替换 master 槽等一系列的操作 */
        clusterFailoverReplaceYourMaster();
    } else {
        clusterLogCantFailover(CLUSTER_CANT_FAILOVER_WAITING_VOTES);
    }
}

如果我们的 master 在 FAIL 状态下, 我们的 epoch 会加一, 并且要求所有其他的至少服务一个槽的 master 节点对我自己进行投票

elect3
并且 master 只会在符合以下条件时进行投票

/* 对于要求给他进行投票的节点, 符合以下条时进行投票 */
void clusterSendFailoverAuthIfNeeded(clusterNode *node, clusterMsg *request) {
    clusterNode *master = node->slaveof;
    uint64_t requestCurrentEpoch = ntohu64(request->currentEpoch);
    uint64_t requestConfigEpoch = ntohu64(request->configEpoch);
    unsigned char *claimed_slots = request->myslots;
    int force_ack = request->mflags[0] & CLUSTERMSG_FLAG0_FORCEACK;
    int j;

    /* 如果我们不是一个至少服务一个槽的节点, 我们是没有权利进行投票的
     * 因为集群的大小为 至少服务一个槽的节点的数量, 并且合法投票数的阈值是 集群大小 + 1 */
    if (nodeIsSlave(myself) || myself->numslots == 0) return;

    /* 要求投票的 epoch 数必须大于等于我们自身的 epoch 数
     * 因为只要请求的 epoch 数比我们自身的 epoch 数大, 我们自己的 epoch 数就会置为请求的 epoch 数, 所以在请求之后实际上请求的 epoch 是不会大于我们自身的 epoch 的 */
    if (requestCurrentEpoch < server.cluster->currentEpoch) {
        serverLog(LL_WARNING,
            "Failover auth denied to %.40s: reqEpoch (%llu) < curEpoch(%llu)",
            node->name,
            (unsigned long long) requestCurrentEpoch,
            (unsigned long long) server.cluster->currentEpoch);
        return;
    }

    /* 我已经对这一轮 epoch 进行过投票了 ? 马上返回 */
    if (server.cluster->lastVoteEpoch == server.cluster->currentEpoch) {
        serverLog(LL_WARNING,
                "Failover auth denied to %.40s: already voted for epoch %llu",
                node->name,
                (unsigned long long) server.cluster->currentEpoch);
        return;
    }

    /* 请求投票的节点必须是一个 slave 并且它的 master 当前处于无法连接的状态
     * 但是请求带有 CLUSTERMSG_FLAG0_FORCEACK 标记时可以例外
     * /
    if (nodeIsMaster(node) || master == NULL ||
        (!nodeFailed(master) && !force_ack))
    {
        if (nodeIsMaster(node)) {
            serverLog(LL_WARNING,
                    "Failover auth denied to %.40s: it is a master node",
                    node->name);
        } else if (master == NULL) {
            serverLog(LL_WARNING,
                    "Failover auth denied to %.40s: I don't know its master",
                    node->name);
        } else if (!nodeFailed(master)) {
            serverLog(LL_WARNING,
                    "Failover auth denied to %.40s: its master is up",
                    node->name);
        }
        return;
    }

    /* 我们在 cluster_node_timeout * 2 的延时内是不会对对应节点的 slave 进行投票的
     * 这不是为了算法的准确性而做的设计, 而是为了表现得更平稳一些 */
    if (mstime() - node->slaveof->voted_time < server.cluster_node_timeout * 2)
    {
        serverLog(LL_WARNING,
                "Failover auth denied to %.40s: "
                "can't vote about this master before %lld milliseconds",
                node->name,
                (long long) ((server.cluster_node_timeout*2)-
                             (mstime() - node->slaveof->voted_time)));
        return;
    }

    /* 要求投票的 slave 必须拥有 >= 他自己的 master 的槽数(在当前节点的 epoch) */
    for (j = 0; j < CLUSTER_SLOTS; j++) {
        if (bitmapTestBit(claimed_slots, j) == 0) continue;
        if (server.cluster->slots[j] == NULL ||
            server.cluster->slots[j]->configEpoch <= requestConfigEpoch)
        {
            continue;
        }
        /* 进到这里, 我们发现了至少一个我们在服务的槽, 同时也在被要求投票的节点的 master 服务着
         * 并且这个 master 的 epoch 大于请求的 epoch, 我们需要拒绝本次投票 */
        serverLog(LL_WARNING,
                "Failover auth denied to %.40s: "
                "slot %d epoch (%llu) > reqEpoch (%llu)",
                node->name, j,
                (unsigned long long) server.cluster->slots[j]->configEpoch,
                (unsigned long long) requestConfigEpoch);
        return;
    }

    /* 我们可以对这个 slave 进行投票 */
    server.cluster->lastVoteEpoch = server.cluster->currentEpoch;
    node->slaveof->voted_time = mstime();
    clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG|CLUSTER_TODO_FSYNC_CONFIG);
    clusterSendFailoverAuth(node);
    serverLog(LL_WARNING, "Failover auth granted to %.40s for epoch %llu",
        node->name, (unsigned long long) server.cluster->currentEpoch);
}

只要这个 slave 获得了集群中超过一半的有效投票, 那么它就会变成 master

elect4
并且因为这个 master 当前有更高的 epoch 数, 如果之前宕机的 master 此时重新恢复并加入集群, 他会根据更高的 epoch 的节点的配置更新, 并且变成新的 master 的 slave

elect5
真实世界的情况会更加复杂, 比如多个从节点的投票竞争, 或者网络分区, 课可以查阅更多资料了解相关信息, 比如 raft 论文

zp0int
关注
专栏目录
Redis——Redis Cluster集群原理
庄小焱
03-14 4707
摘要 我们平时习惯于使用 Rabbitmq 和 Kafka 作为消息队列中间件，来给应用程序之间增加异步消息传递功能。这两个中间件都是专业的消息队列中间件，特性之多超出了大多数人的理解能力。使用过 Rabbitmq 的同学知道它使用起来有多复杂，发消息之前要创建 Exchange，再创建 Queue，还要将 Queue 和 Exchange 通过某种规则绑定起来，发消息的时候要指定 routingkey，还要控制头部信息。消费者在消费消息之前也要进行上面一系列的繁琐过程。但是绝大多数情况下，虽然我们的消息
2021-06-29 redis-cluster集群failover的处理
悟世之路
06-29 411
摘要: 在paxos和raft一致性协议中, 选举是分多轮次进行。当本轮选举未达成一致时, 则进行下轮选举。 redis的cluster集群未使用多轮 进行，本文讨论redis的设计。 核心代码： /* It is possible that we received more updated offsets from other * slaves for the same master since we computed our election delay. *
深入理解redis cluster的failover机制
weixin_34366546的博客
09-12 5189
社区版redis cluster是无中心节点P2P的集群架构，内部采用gossip协议传递维护集群的拓扑结构和集群元数据。社区文档地址：https://redis.io/topics/cluster-tutorial failover是redis cluster提供的容错机制，cluster最核心的功能之一。failover支持两种模式： ...
Redis Sentinel：集群Failover解决方案
pi9nc的专栏
12-31 1万+
Redis Sentinel：集群Failover解决方案 博客分类： Redis Redis sentinel(哨兵)模块已经被集成在redis2.4+的版本中,尽管目前不是release,不过可以尝试去使用和了解,事实上sentinel还是有点复杂的. sentinel主要功能就是为Redis M-S(master,slaves)集群提供了1)master存活检
Redis源码解读（二十五）——集群模式—failover
yh88623131的博客
07-04 1086
Redis集群模式failover解析
Redis cluster集群 故障转移
爱与不爱，一念之间
03-27 4074
Redis集群自身实现了高可用，通过增加Slave从节点做standby数据副本，能够实现故障自动转移，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。当集群内少量节点出现故障时通过自动故障转移保证集群可以正常对外提供服务。 一、故障发现 Redis集群内节点通过ping/pong消息实现节点通信，消息不但可以传播节点槽...
Redis Cluster集群failover
zhannk的专栏
06-21 3254
关于master/slave的failover，redis cluster通过cluster-node-timeout设置节点间状态检测超时。 如果在redis中执行命令比较耗时，比如超过cluster-node-timeout时长，集群master和slave很容易触发failover，频繁的failover容易导致集群状态的变化。 为了验证集群的变化，可以通过如下加负载lua脚本来模拟...
redis 集群 gossip 源码分析
zpoint's blog
01-19 452
gossip 以后都在 github 更新，请戳 redis 集群->gossip 目录 cluster bus 什么时候会发送消息 ping pong cluster bus 来自 cluster-tutorial 每一个 Redis 集群节点需要两条 TCP 连接, 通用的 TCP 端口用来和客户端进行交互, 比如 6379. 还有一个从通用端口加上一万以后的端口, 比如 1637...
redis 集群 reshard 源码分析
zpoint's blog
01-19 759
cluster 以后都在 github 更新，请戳 redis 集群->reshard 目录 相关位置文件 集群 槽 reshard gossip failover 更多资料 相关位置文件 redis/src/cluster.c redis/src/cluster.h 集群 如果我们启动一个集群 mkdir cluster-test cd cluster-test mkdir 700...
Redis监控新工具：Redis-集群监控之Redis monitor源码分析
NRedis-Proxy中间件具备自动failover功能，从而保证了Redis集群的高可用性。 ***ty作为通信传输工具: netty是一个高性能的网络应用框架，用于简化网络编程，如TCP和UDP套接字服务器。在NRedis-Proxy中间件中，使用...
redis cluster集群的源码分析(1)
wade1991的专栏
12-07 2966
对于cluster.c的源码分析，我将会分两部分介绍。本文主要分析集群通信和通信故障。 先大致归纳下cluster的主要函数 void clusterCron(void);//集群的定时任务 int clusterProcessPacket(clusterLink *link);//消息处理中心 void clusterProcessGossipSection(clusterMsg *hdr...
redis源码日志（源码分析）
01-27
redis源码日志是对redis源码的分析解读，适用于学习。 介绍了redis是如何实现高并发、海量数据存贮的。 资源是PDF格式，有完整书签，也很清晰。
Redis cluster 从库自动failover机制
灯火觅阑珊
06-13 2015
目录 一、每个节点维护的信息 二、故障发现（主观下线） 三、客观下线 1.下线报告链表 2.pfail到fail的转变 四、从库通过clusterCron发起自动切换 五、主库投票 六、从库执行切换 七、纪元更新 一、每个节点维护的信息 每个节点内的clusterState结构保存集群信息，从库自身视角所维护的一些信息。结构关键属性如下： 在cluster.h文件中： typedef struct clusterState { clusterNode *myself; .
缓存学习（十）：分布式Redis之Redis Cluster
Yhc不是咸鱼
05-09 3353
目录 1数据拆分 2 Redis Cluster配置 3集群搭建 4集群命令 4.1redis-cli的集群管理模式 4.2客户端命令 5原理 5.1节点通信 5.2槽的迁移 5.2.1集群收缩 5.2.2集群扩容 5.3请求路由和重定向 5.4故障转移 6 JedisCluster 6.1集群节点的自动发现 6.2JedisClus...
Redis6 服务端配置 config命令介绍
ElendaLee的专栏
05-22 1215
config命令介绍（都有默认值） 可以动态地调整 Redis 服务器的配置(configuration)而无须重启 config get xxx、config set xxx 登录redis客户端 [root@localhost bin]# ./redis-cli -a 1qazXSW@ 键入 config get * 可查看所有配置信息 127.0.0.1:6379> config get * 1) "rdbchecksum" 2) "yes" 3) "d...
LeetCode 538 把二叉树转为累加数 HERODING的LeetCode之路
HERODING23的博客
09-21 594
给定一个二叉搜索树（Binary Search Tree），把它转换成为累加树（Greater Tree)，使得每个节点的值是原来的节点值加上所有大于它的节点值之和。 例如： 输入: 原始二叉搜索树: 5 / \ 2 13 输出: 转换为累加树: 18 / \ 20 13 解题思路： 刚开始写这道题感觉挺疑惑的，这挺复杂的题目为什么会是简单题呢，后来仔细观察题目终于发现了，这是个二叉搜索树，那么就代表着对于每个节点，其右子节点的值一定比当前节点值大，左子节点的值一定比当前值小，那么左
redis集群故障分析
热门推荐
daiyudong2020的博客
09-10 1万+
故障表象： 业务层面显示提示查询redis失败 集群组成： 3主3从，每个节点的数据有8GB 机器分布： 在同一个机架中， xx.x.xxx.199 xx.x.xxx.200 xx.x.xxx.301 redis-server进程状态： 通过命令ps -eo pid,lstart | grep $pid， 发现进程已经持续运行了3个月 发生故
redis日志说明与解析成为csv文件
CleverCode的博客
02-04 1030
1 redis日志内容如下 124741:M 04 Feb 14:31:06.589 * Marking node 6b260964244b6d955783ca0abef1582dd1873af9 as failing (quorum reached). 124741:M 04 Feb 14:31:07.309 # Failover auth granted to 2c5e6f8010e32c44...
redis 普通客户端请求超过client-output-buffer-limit限制，导致主从连接断开的问题
耕云者~
09-20 1万+
超过 client-output-buffer-limit 限制，导致主从连接断开的问题一、问题二、查看资料三、对比分析 一、问题 今天收到报警，两个节点之间连接断了，登录节点查看信息，发现已经恢复，好像并没有问题。 但是查看这两个redis节点的日志如下： 可以看出第一个节点收到主节点断开的消息，然后自己成为主库。之后又收到主节点好了的消息，就又把master让给了之前的主节点，开始复制主节点...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值