zookeeper原理_hadoop高可靠性（持续更新~）

已于 2024-05-21 09:20:22 修改
阅读量774 收藏 27
点赞数 14
分类专栏： 大数据技术栈专栏 文章标签： sqlserver hadoop 数据仓库
于 2024-05-16 23:32:08 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_63593025/article/details/138978696
版权

文章目录

zookeeper原理及hadoop高可靠性

一、ZooKeeper底层原理

1、ZK概述

ZooKeeper概念: Zookeeper是一个分布式协调服务的开源框架。本质上是一个分布式的小文件存储系统
ZooKeeper作用: 主要用来解决分布式集群中应用系统的一致性问题。HA搭建；管理去中心化的集群（例如Kafka）
ZooKeeper结构: 采用树形层次结构，ZooKeeper树中的每个节点被称为—Znode。且树中的每个节点可以拥有子节点

在这里插入图片描述

2、ZK集群环境

在这里插入图片描述

zookeeper: 分布式协调服务,搭建高可用时,至少需要两个hadoop服务,一主一备,主服务对外提供业务功能,
备用等待主服务不可用时,启用备用服务器对外提供业务功能
zookeeper的服务角色分别为:
    leader: 管理者 ,负责管理follower,处理所有的事务请求(数据的保存,修改,删除)
    follower: 追随者,负责选举(选举leader)和数据的同步及获取
    observer: 观察者,负责数据的同步及获取(需要在配置文件中指定才能生效)

    
zookeeper应用:  
	1- 搭建HA。例如: namenode的HA（high avaliable）
	2- 管理去中心化的集群。例如: Kafka集群

3、ZK启动和使用

详细操作步骤参考扩展资料中的【大数据集群环境搭建.md】

3.1 配置环境变量

配置zookeeper环境变量**(注意三台都单独配置!!!)**

可以使用CRT客户端发送以下命令到三台

[root@nodex ~]# echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >> /etc/profile
[root@nodex ~]# echo 'export PATH=$PATH:$ZOOKEEPER_HOME/bin' >> /etc/profile
[root@nodex ~]# source /etc/profile

3.2 启动集群

启动zookeeper服务**(注意三台都单独需要启动!!!)**

可以使用CRT客户端发送以下命令到三台

[root@nodex ~]# zkServer.sh start

还可以查看服务状态: [root@node]# zkServer.sh status

关闭zk服务的命令是: [root@node]# zkServer.sh stop

3.3 客户端连接

连接服务
方式1:直接连接本地: [root@node1 ~]# zkCli.sh
方式2:连接其他节点: [root@node1 ~]# zkCli.sh -server 节点地址

[root@node1 ~]# zkCli.sh

3.4 ZK的shell命令

知识点:

查看所有shell命令: help

create [-s] [-e] 节点绝对路径 节点数据: 创建数据节点    注意: -s代表序列化节点    -e代表临时节点

delete 节点绝对路径 [version]: 删除一级节点  注意: 此方式如果有子节点是不能删除的
rmr 节点绝对路径: 删多层除节点(如果有子节点也可以删除)

set 节点绝对路径 data [version]: 设置 /修改节点数据

get 节点绝对路径 [watch]: 获取数据    注意: watch是监听
ls 节点绝对路径  : 查看节点信息        举例: 查看根路径下节点   ls /
ls2 节点绝对路径 : 查看节点详情信息
history: 查看操作历史

quit: 退出

示例:

[root@node1 ~]# zkCli.sh
...
WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 1] create /binzi 666
Created /binzi
[zk: localhost:2181(CONNECTED) 2] create /binzi/b1 111
Created /binzi/b1
[zk: localhost:2181(CONNECTED) 3] create /binzi/b2 222
Created /binzi/b2

[zk: localhost:2181(CONNECTED) 4] ls /
[binzi, zookeeper]
[zk: localhost:2181(CONNECTED) 5] ls /binzi
[b2, b1]
[zk: localhost:2181(CONNECTED) 6] set /binzi 888
...
[zk: localhost:2181(CONNECTED) 7] get /binzi
888
...

[zk: localhost:2181(CONNECTED) 8] delete /binzi/b1
[zk: localhost:2181(CONNECTED) 9] ls /binzi
[b2]

# 注意: delete不能删除有子节点的节点
[zk: localhost:2181(CONNECTED) 10] delete /binzi
Node not empty: /binzi 
# rmr可以删除多层节点
[zk: localhost:2181(CONNECTED) 11] rmr /binzi
[zk: localhost:2181(CONNECTED) 12] ls /
[zookeeper]

[zk: localhost:2181(CONNECTED) 13] history
...
[zk: localhost:2181(CONNECTED) 14] quit
Quitting...shut down
[root@node1 ~]#

4、ZK的节点特性和分类

4.1 节点特性

ZooKeeper的数据模型，在结构上和标准文件系统的非常相似，都是采用树形层次结构，和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。
但也有不同之处：

Znode兼具文件和目录两种特点: Znode没有文件和目录之分,Znode既有像文件一样存储数据,也能像目录一样作为路径标识的一部分

Znode具有原子性操作: 读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据

Znode存储数据大小有限制: 每个Znode的数据大小至多1M，当时常规使用中应该远小于此值

Znode通过路径引用: 路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。  默认有/zookeeper节点用以保存关键的管理信息。

4.2 节点分类

节点分类: 永久普通节点,临时普通节点,永久序列化节点,临时序列化节点

创建永久普通节点:  create /节点 数据

创建临时普通节点:  create -e /节点 数据

创建永久序列化节点: create -s /节点 数据

创建临时序列化节点: create -e -s /节点 数据

注意: 临时节点不能创建子节点

4.3 节点属性

每个znode都包含了一系列的属性，通过命令get /节点，可以获得节点的属性
注意: 对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。
cZxid ：Znode创建的事务id。
ctime ：Znode创建时的时间戳.

​ mZxid ：Znode被修改的事务id，即每次对当前znode的修改都会更新mZxid。
​ mtime ：Znode最新一次更新发生时的时间戳.

​ pZxid ：Znode的子节点列表变更的事务ID，添加子节点或删除子节点就会影响子节点列表
​ cversion ：子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号

​ dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了 数据更新时出现的先后顺序问题。
​ aclVersion : 权限变化列表版本 access control list Version
​ ephemeralOwner : 字面翻译临时节点拥有者，永久节点值为: 0x0，临时节点值为:会话ID (不是0x0的就是临时节点)
​ dataLength : Znode数据长度
​ numChildren: 当前Znode子节点数量(不包括子子节点）

5、ZK集群特点

1. 全局数据一致: 集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；

2. 可靠性: 如果消息被其中一台服务器接受，那么将被所有的服务器接受。

3. 顺序性: 包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

4. 数据更新原子性: 一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；

5. 实时性: Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

6、watch监听机制

ZooKeeper中，引入了Watcher机制来实现数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。
ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

watch监听机制过程: 客户端向服务端注册Watcher     服务端事件发生触发Watcher     客户端回调Watcher得到触发事件情况
Watch监听机制注册格式:  get /节点绝对路径 watch
Watch监听机制特点:
    先注册再触发: Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端
    一次性触发: 事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。
    异步发送: watcher的通知事件从服务端发送到客户端是异步的。
    通知内容: 通知状态（keeperState），事件类型（EventType）和节点路径（path）

示例：

node1上创建临时节点

[zk: localhost:2181(CONNECTED) 1] create -e /master 1111
Created /master

node2上设置监听

[zk: localhost:2181(CONNECTED) 28] get /master watch

node1退出

[zk: localhost:2181(CONNECTED) 2] quit

node2查看消息

[zk: localhost:2181(CONNECTED) 29] 
WATCHER::

WatchedEvent state:SyncConnected type:NodeDeleted path:/master

7、ZK应用

1. 数据发布/订阅
数据发布/订阅系统,就是发布者将数据发布到ZooKeeper的一个节点上，提供订阅者进行数据订阅，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。

主要用到知识点: 监听机制

2. 提供集群选举
在分布式环境下，不管是主从架构集群，还是主备架构集群，要求在服务的时候有且有一个正常的对外提供服务，我们称之为master。
当master出现故障之后，需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。
主要用到知识点: znode唯一性、临时节点短暂性、监听机制。

选举概述: 
选举要求: 过半原则,所以搭建集群一般奇数,只要某个node节点票数过半立刻成为leader

集群第一次启动: 启动follower每次投票后,他们会相互同步投票情况,如果票数相同,谁的myid大,谁就当选leader,一旦确定了leader,后面来的默认就是follower,即使它的myid大,leader也不会改变(除非leader宕机了)

leader宕机后启动: 每一个leader当老大的时候,都会产生新纪元epoch,且每次操作完节点数据都会更新事务id(高32位_低32位) ,当leader宕机后,剩下的follower就会综合考虑几个因素选出最新的leader,先比较最后一次更新数据事务id(高32位_低32位),谁的事务id最大,谁就当选leader,如果更新数据的事务id都相同的情况下,就需要再次考虑myid,谁的myid大,谁就当选leader

二、Hadoop高可用

1、概述

​ hadoop2.x之后，Cloudera提出了QJM/Qurom Journal Manager，这是一个基于Paxos算法（分布式一致性算法）实现的HDFS HA方案，它给出了一种较好的解决思路和方案,QJM主要优势如下：不需要配置额外的高共享存储，降低了复杂度和维护成本。消除spof(单点故障)。系统鲁棒性(Robust)的程度可配置、可扩展。

​ 在HA架构里面SecondaryNameNode已经不存在了，为了保持standby NN, 实时的与Active NN的元数据保持一致，他们之间交互通过JournalNode进行操作同步。

​ 任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录修改log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的目录镜像文件里面

​ 当发生故障时，Active的 NN 挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像文件一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。

​ 在HA模式下，datanode需要确保同一时间有且只有一个NN能命令DN。为此：每个NN改变状态的时候，向DN发送自己的状态和一个序列号。

​ DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active。

​ 如果这时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。

Failover Controller
​ HA模式下，会将FailoverController部署在每个NameNode的节点上，作为一个单独的进程用来监视NN的健康状态。

FailoverController主要包括三个组件:
​ HealthMonitor: 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成。

​ ActiveStandbyElector: 监控NN在ZK中的状态。

​ ZKFailoverController: 订阅HealthMonitor 和ActiveStandbyElector 的事件，并管理NN的状态,另外zkfc还
负责解决fencing（也就是脑裂问题）。

JournalNode进程作用: 任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录修改log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的目录镜像文件里面

DFSZKFailoverController进程作用: 1. 健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态2.会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN将会得到这把锁，升级为主NN，同时标记状态为Active3.master选举：通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态4.当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠

在这里插入图片描述

2、高可用服务

NN: NameNode
DN: DataNode

RM: ResourceManager
NM: NodeManager

JN: JournalNode
ZK: ZooKeeper
ZKFC: DFSZKFailoverController

在这里插入图片描述

3、启动hadoop高可用环境

# 1.先恢复快照到高可用环境

# 2.三台服务器启动zookeeper服务
[root@node1 ~]# zkServer.sh start
[root@node2 ~]# zkServer.sh start
[root@node3 ~]# zkServer.sh start

# 3.在node1中启动hadoop集群
[root@node1 ~]# start-all.sh

# 4.检查服务
[root@node1 ~]# jps
[root@node2 ~]# jps
[root@node3 ~]# jps

在这里插入图片描述

4、NameNode高可用

web链接:

node1:50070

node2:50070

可以使用kill -9 NN进程号把其中主服务杀掉,观察效果,然后使用 hdfs --daemon start namenode 重启,再次观察效果

在这里插入图片描述
在这里插入图片描述

active: namenode主服务
standby: namenode备份服务

5、ResourceManager高可用

web链接:

node1:8088

node2:8088

可以使用kill -9 RM进程号把其中主服务杀掉,观察效果,然后使用 yarn --daemon start resourcemanager 重启,再次观察效果

注意: 两个服务同时启动,按照上述链接去访问会自动跳到同一个主节点页面

–daemon start namenode== 重启,再次观察效果

[外链图片转存中…(img-ik6QsHN2-1715873074147)]

[外链图片转存中…(img-NqpCA2iP-1715873074148)]

active: namenode主服务
standby: namenode备份服务

5、ResourceManager高可用

web链接:

node1:8088

node2:8088

可以使用kill -9 RM进程号把其中主服务杀掉,观察效果,然后使用 yarn --daemon start resourcemanager 重启,再次观察效果

注意: 两个服务同时启动,按照上述链接去访问会自动跳到同一个主节点页面

在这里插入图片描述

IT界的追风者
关注
  • 14
    点赞
  • 踩
  • 27
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
带你搞明白Zookeeper的内部原理
大数据技术开发
03-12 1138
今天来看下zookeeper是干什么的，以及zookeeper的内部原理。
JAVA核心面试知识-Zookeeper（十一）
小王的博客
12-20 439
Zookeeper 概念 Zookeeper 是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。 Zookeeper 提供了一个类似于 Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。 11.1.1. Zookeeper 角色 Zookeeper 集群是一个基于主...
Zookeeper 工作机制和底层原理解析
weixin_53172154的博客
07-19 83
接收观察者的注册，一旦数据发生变化，zookeeper负责通知已经在zookeeper上注册的那些观察者做出相应的反应，Zookeeper接收请求处理流程： 请求---日志----持久化---更新datatree。1）Zookeeper:一个领导（leader）,多个跟随者（Follower）组成的集群。集群投票，每个zookeep都有自己的投票箱，先给自己投，再按照上面的规则投。4）更新请求的顺序进行，来自同一个client的更新请求按照发送顺序依次执行。每个节点默认存储1兆数据，
Zookeeper实现原理分析
qq_43752469的博客
12-12 2562
一、zookeeper概述 1、zookeeper：是一个开源的、分布式的，为分是不是框架提供协调服务的Apache框架。 2、zookeeper工作机制：基于观察者模式设计的分布式服务管理框架，负责存储和管理大家都关心的数据，然后接收观察者的注册，一旦数据状态发生变化，zookeeper将负责通知已经在zookeeper上注册的那些观察者做出相应的反应。 3、zookeeper特点： 一个领导者leader，多个跟随着follower组成的集群。 集群中只要有半数以上节点存活，zookeeper集群就能
zookeeper底层原理讲解
Mirror_w的博客
05-25 5639
zookeeper是一个分布式的协调系统协调系统。zookeeper保证了数据在ZK之间数据的事务性的一致性。其中zookeeper提供了分布式的锁服务，用于协调分布式应用程序。zookeeper的应用主要有储存元数据信息和选举机制。例如在hadoop中可以利用zookeeper选取namenode的active状态，可以在znode下储存对应的信息，来决定哪台nameNode是active状态...
Hadoop HA高可用详细配置，100分也不贵
04-11
### Hadoop HA高可用配置详解 #### 一、HA机制-高可用性 在Hadoop集群中实现高可用性(HA)是确保集群稳定运行的关键技术...通过这种方式配置的Hadoop集群能够在发生故障时快速恢复，大大提高了系统的稳定性和可靠性。
zookeeper文件
08-11
Zookeeper是Apache Hadoop项目下的一个分布式协调服务，它为分布式应用提供了一种高效且可靠的分布式协调机制...通过本地搭建Zookeeper伪集群，我们可以更好地理解和测试其功能，进一步优化分布式应用的性能和可靠性。
hadoop大数据生态圈组件
01-20
3. Flume：Flume是Cloudera开发的一个高可用、高可靠的分布式日志收集系统。它可以轻松地从各种数据源（如网络服务器日志）收集数据，然后将数据传输到集中存储系统，如HDFS。 4. HBase：HBase是一个基于Hadoop的...
HadoopHA集群部署、规划HadoopHA集群教学课件.pptx
06-20
【Hadoop HA 集群部署详解】 在大数据领域，Hadoop HA（高可用性）是确保服务持续可用的关键技术，特别是在...正确配置和管理这些组件，能确保Hadoop集群在面对单点故障时仍能提供稳定的服务，提高整体系统的可靠性。
一文彻底揭开Zookeeper的底层机制
最新发布
禅与计算机程序设计艺术
01-25 580
1.背景介绍 Zookeeper是一个开源的分布式协调服务，它为分布式应用提供一致性、可靠性和原子性的数据管理。Zookeeper的底层机制非常复杂，但也非常有趣。在本文中，我们将深入揭开Zookeeper的底层机制，揭示其如何实现高可靠性、一致性和原子性的数据管理。 1. 背景介绍 Zookeeper的核心功能是为分布式应用提供一致性、可靠性和原子性的数据管理。它的核心功能包括： 数据...
zookeeper的ZAB协议的原理以及底层源码实现超级详解
zl5186888的博客
09-07 421
接下来就是主要查看一下这个创建命令，主要是通过这个 pRequest2Txn 方法实现，并且里面的这个参数zxid，是一个automic的一个原子类型，不存在这个线程安全问题。10，在执行这个链条的过程中，会通过这个prepRequestProcessor这个线程来读取加在服务端队列的里面的消息，接下来主要就是查看这个线程里面的run方法。主要用来实现数据的传输。2，然后进入这个开始连接的start方法，这个方法里面主要是会去开启两个线程，一个线程主要用来连接服务端，一个线程主要用来响应连接后的事件。
Zookeeper底层原理分析
05-20
ZooKeeper 是一个 分布式 的，开放源码的分布式 应用程序协调服务 ，本课程主要对ZooKeeper的底层原理进行分析，主要包括Zookeeper原理，Zookeeper是如何解决数据一致性问题以及Zookeeper领导者选举原理等内容。
Zookeeper底层源码原理分析（一）
weixin_45577149的博客
05-06 465
1、zk是什么？ 它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、集群管理、分布式应用配置项的管理等。 （1）、 zk是一个数据库 其可以存数据， ls /（查看根节点） create /luban 123（创建数据节点，内容为123） get /luban（查询） zk中有临时节点，也有持久化节...
Zookeeper深度解析（概念、原理机制、应用场景）
热门推荐
wzk646795873的博客
03-27 2万+
1、Zookeeper是什么？分布、开源的应用程序协调服务,它是集群的管理者,监视着集群中各个节点的状态，根据节点的反馈进行下一步合理操作。主要解决分布式应用经常遇到的数据管理问题,如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。（Zookeeper 作为 Hadoop 项目中的一个子项目，是 Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理 H...
20200420——Zookeeper底层深入 源码剖析 一
寄蜉蝣于天地，渺沧海之一粟。
04-20 192
ZooKeeper 是个针对大型分布式系统的高可用、高性能且具有一致性的开源协调服务，被广泛的使用。对于开发人员，ZooKeeper 是一个学习和实践分布式组件的不错的选择。 前言 在业务中使用了 ZooKeeper 作为消息系统，在开发和运维过程中，也遇到一些问题，萌发了阅读源码窥视实现细节的想法。同时我们运维的 ZooKeeper 集群规模和数据规模非常大，也想把运维的经验分享出来供参考去规避...
Zookeeper内部原理概述
weixin_42146366的博客
03-26 1万+
一、Zookeeper简单介绍 ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。 二、Zookeeper的工作机制 Zookeeper从设计模式的角度来理解：是一个基于观察者模式的分布式服务管理框架...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

IT界的追风者

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

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

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

打赏作者

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

抵扣说明：

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

余额充值