第五天 -- Kafka

最新推荐文章于 2022-04-02 17:47:43 发布
最新推荐文章于 2022-04-02 17:47:43 发布
阅读量630 收藏 1
点赞数
分类专栏： 学习 文章标签： kafka基础
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cry970795248/article/details/84536297
版权

第五天 – Kafka基础

文章目录

一、Kafka简介

​ Kafka是一个分布式消息队列：生产者和消费者的功能。该框架的目标是为处理实时数据提供一个统一、高吞吐量、低等待的平台。它提供了类似于JMS的特性，但是在设计实现上完全不同，此外它并不是JMS规范的实现。

​ Kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接收者称为Consumer，此外Kafka集群由多个kafka实例组成，每个实例(server)称为broker。

​ 无论是Kafka集群，还是producer和consumer都依赖于zookeeper集群保存一些meta信息，来保证系统的可用性。

二、JMS相关

JMS简介

​ JMS是Java提供的一套技术规范，用来异构系统，集成通信，缓解系统瓶颈，提高系统的伸缩性增强系统用户体验，使得系统模块化和组件化变得可行并更加灵活。使用生产消费者模式(生产者、服务器、消费者)

1543023215799

JMS消息传输模型

  • 点对点模式(一对一，消费者主动拉取数据，消息收到后消息清除)

    点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信息，而不是将消息推送到客户端，这个模型的特点是发送队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

  • 发布/订阅模式(一对多，数据产生后，推送给所有订阅者)

    发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才能接收消息，而持久订阅者则监听主题的所有消息。

JMS核心组件

  • Destination：消息发送的目的地，也就是前面说的Queue和Topic

  • Message：被发送的消息

  • Producer：消息生产者，要发送一个消息，必须通过这个生产者来发送

  • MessageConsumer：与生产者相对应，这是消息接收者，通过它来接收一个消息

    1543023630681

三、消息队列的重要性

消息系统的核心作用就是三点：解耦、异步和并行。

下面通过用户注册的案例来说明消息系统的作用。

用户注册的一般流程

1543023739336

问题：随着后端流程越来越多，每步流程都需要额外的耗费时间，导致用户更长的等待延迟

用户注册的并行执行

1543023797754

问题：系统并行发起了4个请求，4个请求中，如果某一个环节执行1分钟，其他环节再快，用户也需要等待1分钟，并且如果其中一个环节出现异常后，整个服务也就挂掉了。

用户注册的最终一致

1543023880517

  1. 保证主流程的正常执行、执行成功后，发送MQ(消息队列)出去

  2. 需要这个destination的其他系统通过消费数据再执行，最终一致

    1543024011326

四、Kafka核心组件

Kafka整体结构图

Kafka相关名词解释

  • Producer：消息生产者，就是向kafka broker发送消息的客户端。

  • Consumer：消息消费者，向kafka broker取消息的客户端。

  • Topic：一个队列，消息根据topic进行归类。

  • Consumer Group(CG)：这是kafka用来实现一个topic消息的广播(发送给所有的consumer)和单播(发送给任意一个consumer)的手段。一个topic可以有多个CG。topic的消息会复制(不是真正的物理复制，只是概念上的)到所有的CG，但每个partition只会把消息发给该CG中的一个consumer。如果需要实现广播，需要每个consumer有一个独立的CG。用CG还可以将consumer进行自由分组而不需要多次发送消息到不同的topic。

  • Broker：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

  • Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id(offset)。kafka只保证按一个partition中的顺序将消息发送给consumer，不保证一个topic的整体(多个partition间)的顺序。

  • Offset：kafka的存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如如果想找位于2018的位置，只要找到2017.kafka的文件即可。当然the first offset就是00000000000.kafka。

Consumer与Topic的关系

本质上kafka只支持topic

  • 每个group中可以有多个consumer，每个consumer都有一个cg；通常情况下，一个cg会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高"故障容错"性，如果group中某个consumer失效，那么其消费的partition将会有其他consumer自动接管。
  • 对于topic中的一条特定的消息，只会被订阅此topic的每个group中的其中一个consumer消费，此消息不会发送给一个cg中的多个consumer；那么一个group中所有的consumer将会交错地消费整个topic，每个group中consumer消息消费互相独立我们可以认为一个group是一个订阅者。
  • 在kafka中，一个partition中的消息在同一时刻只会被group中的consumer消费；一个topic中的每个partition，只会被一个订阅者中的一个consumer消费，不过一个consumer可以同时消费多个partition中的消息。
  • kafka的设计原理决定，对于一个topic，同一个group中不能有多于partition个数的consumer同时消费，否则意味着某些consumer无法得到消息。
  • kafka只能保证一个partition中的消息被某个consumer消费时是有序的，从topic角度来说，当有多个partition时，消息并不会是全局有序的
Kafka消息的分发

Producer客户端负责消息的分发

  • kafka集群中的任何一个broker都可以向Producer提供metadata信息，这些metadata中包含"集群中存活的servers列表"/"partitions leader"等信息。
  • 当Producer获取到metadata信息之后，producer将会和topic下所有partition leader保持socket连接。
  • 消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"，事实上，消息被路由到哪个partition由producer客户端决定。比如可以采用"random"“key-hash”"轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。
  • 在producer端的配置文件中，开发者可以指定partition路由的方式

Producer消息发送的应答机制

设置发送数据是否需要服务端的反馈，有三个值0,1，-1：

0：producer不会等待broker发送ack

1：当leader接收到消息之后发送ack

-1：当所有的follower都同步消息成功后发送ack

ack：确认字符

request.required.acks=0

Consumer的负载均衡

当一个group中，有consumer加入或者离开时，会触发partitions负载均衡，负载均衡的最终目的是提升topic的并发消费能力，步骤如下：

  1. 假如topic1，具有如下partitions：P0, P1, P2, P3
  2. 假如group中，有如下consumer：C0, C1
  3. 首先根据partition索引号对partitions排序：P0, P1, P2, P3
  4. 根据consumer.id排序：C0, C1
  5. 计算倍数：M = [P0, P1, P2, P3].size / [C0, C1].size，向上取整
  6. 然后依次分配partitions: C1 = [P0, P1], C2 = [P2,P3], 即Ci = [P(i * M),P((i + 1) * M - 1)]

五、Kafka集群部署

下载安装

安装的Kafka版本是kafka_2.11-0.9.0.1，下载后上传至Linux服务器中。

解压安装包

tar -zxvf kafka_2.11-0.9.0.1.tgz -C /home/bigdata/installsoft/

修改配置文件

进入kafka的配置文件目录

cd /home/bigdata/installsoft/kafka_2.11-0.9.0.1/config

需要修改三个文件：server.properties、producer.properties、consumer.properties

server.properties

#broker的全局唯一编号，不能重复
broker.id=0
#用来监听链接的端口，producer或consumer将在此端口建立连接
port=9092
#处理网络请求的线程数量
num.network.threads=3
#用来处理磁盘IO的线程数量
num.io.threads=8
#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400
#接受套接字的缓冲区大小
socket.receive.buffer.bytes=102400
#请求套接字的缓冲区大小
socket.request.max.bytes=104857600
#kafka消息存放的路径
log.dirs=/home/bigdata/logs/kafka
#topic在当前broker上的分片个数
num.partitions=2
#用来恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1
#segment文件保留的最长时间，超时将被删除
log.retention.hours=168
#滚动生成新的segment文件的最大时间
log.roll.hours=168
#日志文件中每个segment的大小，默认为1G
log.segment.bytes=1073741824
#周期性检查文件大小的时间
log.retention.check.interval.ms=300000
#日志清理是否打开
log.cleaner.enable=true
#broker需要使用zookeeper保存meta数据
zookeeper.connect=cdhnocms01:2181,cdhnocms02:2181,cdhnocms03:2181
#zookeeper链接超时时间
zookeeper.connection.timeout.ms=6000
#partion buffer中，消息的条数达到阈值，将触发flush到磁盘
log.flush.interval.messages=10000
#消息buffer的时间，达到阈值，将触发flush到磁盘
log.flush.interval.ms=3000
#删除topic需要server.properties中设置delete.topic.enable=true否则只是标记删除
delete.topic.enable=true
#此处的host.name为本机IP(重要),如果不改,则客户端会抛出:Producer connection to localhost:9092 unsuccessful 错误!
host.name=cdhnocms01

producer.properties

#指定kafka节点列表，用于获取metadata，不必全部指定
metadata.broker.list=cdhnocms01:9092,cdhnocms02:9092
# 指定分区处理类。默认kafka.producer.DefaultPartitioner，表通过key哈希到对应分区
# partitioner.class=kafka.producer.DefaultPartitioner
# 是否压缩，默认0表示不压缩，1表示用gzip压缩，2表示用snappy压缩。压缩后消息中会有头来指明消息压缩类型，故在消费者端消息解压是透明的无需指定。
compression.codec=none
# 指定序列化处理类
serializer.class=kafka.serializer.DefaultEncoder
# 如果要压缩消息，这里指定哪些topic要压缩消息，默认empty，表示不压缩。
#compressed.topics=
# 设置发送数据是否需要服务端的反馈,有三个值0,1,-1
# 0: producer不会等待broker发送ack 
# 1: 当leader接收到消息之后发送ack 
# -1: 当所有的follower都同步消息成功后发送ack. 
request.required.acks=0 
# 在向producer发送ack之前,broker允许等待的最大时间 ，如果超时,broker将会向producer发送一个error ACK.意味着上一次消息因为某种原因未能成功(比如follower未能同步成功) 
request.timeout.ms=10000
# 同步还是异步发送消息，默认“sync”表同步，"async"表异步。异步可以提高发送吞吐量,
# 也意味着消息将会在本地buffer中,并适时批量发送，但是也可能导致丢失未发送过去的消息
producer.type=sync
# 在async模式下,当message被缓存的时间超过此值后,将会批量发送给broker,默认为5000ms
# 此值和batch.num.messages协同工作.
queue.buffering.max.ms = 5000
# 在async模式下,producer端允许buffer的最大消息量
# 无论如何,producer都无法尽快的将消息发送给broker,从而导致消息在producer端大量沉积
# 此时,如果消息的条数达到阀值,将会导致producer端阻塞或者消息被抛弃，默认为10000
queue.buffering.max.messages=20000
# 如果是异步，指定每次批量发送数据量，默认为200
batch.num.messages=500
# 当消息在producer端沉积的条数达到"queue.buffering.max.meesages"后 
# 阻塞一定时间后,队列仍然没有enqueue(producer仍然没有发送出任何消息) 
# 此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制"阻塞"的时间 
# -1: 无阻塞超时限制,消息不会被抛弃 
# 0:立即清空队列,消息被抛弃 
queue.enqueue.timeout.ms=-1
# 当producer接收到error ACK,或者没有接收到ACK时,允许消息重发的次数 
# 因为broker并没有完整的机制来避免消息重复,所以当网络异常时(比如ACK丢失) 
# 有可能导致broker接收到重复的消息,默认值为3.
message.send.max.retries=3
# producer刷新topic metada的时间间隔,producer需要知道partition leader的位置,以及当前topic的情况 
# 因此producer需要一个机制来获取最新的metadata,当producer遇到特定错误时,将会立即刷新 
# (比如topic失效,partition丢失,leader失效等),此外也可以通过此参数来配置额外的刷新机制，默认值600000 
topic.metadata.refresh.interval.ms=60000

consumer.properties

# zookeeper连接服务器地址
zookeeper.connect=cdhnocms01:2181,cdhnocms02:2181,cdhnocms03:2181
# zookeeper的session过期时间，默认5000ms，用于检测消费者是否挂掉
zookeeper.session.timeout.ms=5000
#当消费者挂掉，其他消费者要等该指定时间才能检查到并且触发重新负载均衡
zookeeper.connection.timeout.ms=10000
# 指定多久消费者更新offset到zookeeper中。注意offset更新时基于time而不是每次获得的消息。一旦在更新zookeeper发生异常并重启，将可能拿到已拿到过的消息
zookeeper.sync.time.ms=2000
#指定消费组
group.id=xxx
# 当consumer消费一定量的消息之后,将会自动向zookeeper提交offset信息 
# 注意offset信息并不是每消费一次消息就向zk提交一次,而是先在本地保存(内存),并定期提交,默认为true
auto.commit.enable=true
# 自动更新时间。默认60 * 1000
auto.commit.interval.ms=1000
# 当前consumer的标识,可以设定,也可以由系统生成,主要用来跟踪消息消费情况,便于观察
conusmer.id=xxx
# 消费者客户端编号，用于区分不同客户端，默认客户端程序自动产生
client.id=xxxx
# 最大取多少块缓存到消费者(默认10)
queued.max.message.chunks=50
# 当有新的consumer加入到group时,将会reblance,此后将会有partitions的消费端迁移到新的consumer上,如果一个consumer获得了某个partition的消费权限,那么它将会向zk注册 "Partition Owner registry"节点信息,但是有可能此时旧的consumer尚没有释放此节点, 此值用于控制,注册节点的重试次数. 
rebalance.max.retries=5
# 获取消息的最大尺寸,broker不会像consumer输出大于此值的消息chunk 每次feth将得到多条消息,此值为总大小,提升此值,将会消耗更多的consumer端内存
fetch.min.bytes=6553600
# 当消息的尺寸不足时,server阻塞的时间,如果超时,消息将立即发送给consumer
fetch.wait.max.ms=5000
socket.receive.buffer.bytes=655360
# 如果zookeeper没有offset值或offset值超出范围。那么就给个初始的offset。有smallest、largest、anything可选，分别表示给当前最小的offset、当前最大的offset、抛异常。默认largest
auto.offset.reset=smallest
# 指定序列化处理类
derializer.class=kafka.serializer.DefaultDecoder
分发安装包

scp -r /home/bigdata/installsoft/kafka_2.11-0.9.0.1/ cdhnocms02:/home/bigdata/installsoft/

scp -r /home/bigdata/installsoft/kafka_2.11-0.9.0.1/ cdhnocms03:/home/bigdata/installsoft/

分发安装包后需要对server.properties再次配置

  1. broker.id三台分别是0,1,2
  2. 修改host.name
kafka集群启动

依次在各个节点上启动kafka

nohup bin/kafka-server-start.sh config/server.properties &

启动完成后，使用jps命令能看到Kafka进程

六、Kafka常用操作命令

  • 创建topic

    bin/kafka-topics.sh --create --zookeeper cdhnocms01:2181 --replication-factor 1 --partitions 1 --topic test

    1543028580079

  • 查看当前服务器中的所有topic

    bin/kafka-topics.sh --list --zookeeper cdhnocms01:2181

    1543028674276

  • 删除topic

    bin/kafka-topics.sh --delete --zookeeper cdhnocms01:2181 --topic test

  • 通过shell命令发送消息

    bin/kafka-console-producer.sh --broker-list cdhnocms01:9092 --topic test1

  • 通过shell命令消费消息

    bin/kafka-console-consumer.sh --zookeeper cdhnocms01:2181 --from-beginning --topic test1

    以上两个命令在不同的窗口使用，可以实现生产者发送消息-消费者接收消息的效果

    1543029031291

    1543029045203

  • 查看消费位置

    bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper cdhnocms01:2181 --group testGroup

  • 查看某个topic的详情

    bin/kafka-topics.sh --topic test1 --describe --zookeeper cdhnocms01:2181

    1543029267734

  • 对分区数进行修改

    bin/kafka-topics.sh --zookeeper cdhnocms01:2181 --alter --partitions 15 --topic test1

    1543029354893

cry970795248
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
kafka-connect-tools:Kafka Connect工具
04-29
/dependency >要求Java 1.8 Gradle5Kafka Connect CLI 这是周围的一个微小的命令行界面（CLI），用于管理连接器。 它以git之类的方式使用，其中第一个程序参数指示命令：它可以是[ps|get|rm|create|run|status|...
Kafka设计解析（五）-KafkaConsumer设计解析
02-25
本文是系列文章的第4篇，第一篇"第二篇第三篇第四篇本文主要介绍了KafkaHighLevelConsumer，ConsumerGroup，ConsumerRebalance，LowLevelConsumer实现的语义，和适用场景。以及未来版本中对HighLevelConsumer的重新...
Android知识点<5>消息机制
ls__today的博客
03-11 180
Android的消息机制，主要指的是Handler机制。1. 背景介绍：一个程序的运行，就是一个进程的在执行，一个进程里面可以拥有很多个线程。主线程：也叫UI线程，或称ActivityThread，用于运行四大组件和处理他们用户的交互。 ActivityThread管理应用进程的主线程的执行(相当于普通Java程序的main入口函数)，在Android系统中，在默认情况下，一个应用程序内的各个组件...
记一次Android OOM问题
z9722的博客
04-02 6291
问题背景： 新平台固件测试后，反馈一个OOM的问题。问题日志如下： 3944 3959 I: Clamp target GC heap from 280MB to 256MB 3944 3959 I: Alloc concurrent copying GC freed 0(0B) AllocSpace objects, 0(0B) LOS objects, 0% free, 256MB/256MB, paused 173us total 383.632ms 3944 3944 I: WaitFo
记录一次cpu 过高分析过程
易水寒冰的博客
01-17 784
cpu 过高的问题 1:cd /tmp 2: 看目录下是否有进程Id命名的文件名 在进入后是有对应服务的进程id的文件，但是没有我想要的线程的id，那为啥没有生成线程的文件了？（如果读者你知道，烦请你告诉我下，在这我会非常感谢你。。。） 3：ps -mp pid -o THREAD,tid,time |sort -rn 将查出来的线程转换成16进制，然后用下面的命令查看对应的堆栈信息 3：使用命令 jstack pid | grep 5760（22368 对应的tid转换成16进制的数据
Spark修炼之道（高级篇）——Spark源码阅读：第九节 Task执行成功时的结果处理...
weixin_33759269的博客
10-29 312
Task执行成功时的结果处理 在上一节中，给出了Task在Executor上的运行代码演示，我们知道代码的最终运行通过的是TaskRunner方法 class TaskRunner( execBackend: ExecutorBackend, val taskId: Long, val attem...
TensorFlow关于队列的简单使用及其理解
so
04-16 507
其他人的理解,很好，所以copy过来了。入队操作都在主线程中进行,Session中可以多个线程一起运行。 在数据输入的应用场景中，入队操作从硬盘上读取,入队操作是从硬盘中读取输入，放到内存当中，速度较慢。 使用QueueRunner可以创建一系列新的线程进行入队操作，让主线程继续使用数据。如果在训练神经网络的场景中，就是训练网络和读取数据是异步的，主线程在训练网络，另一个线程在将数据从硬盘读入内存
kafka-nodejs:NodeJS 和 Kafka 使用 kafka-node
06-10
#集成NODEJS和Kafka ＃＃＃目录 步骤 1 - 将以下脚本复制到名为... 第 5 步 - 检查消费者，您将看到从nodejs发送的消息。 将 JSON 发送到 NodeJS 到 Kafka。 步骤 1 - 使用以下脚本创建一个名为json_nodejs_kafka.
快速学习-Kafka 监控
01-07
第 5 章 Kafka 监控 5.1 Kafka Eagle 修改 kafka 启动命令 修改 kafka-server-start.sh 命令中 if [ x$KAFKA_HEAP_OPTS = x ]; then export KAFKA_HEAP_OPTS=-Xmx1G -Xms1G fi 为 if [ x$KAFKA_HEAP_OPTS = x ]; ...
线程池ThreadPool及Task调度死锁分析
weixin_33725807的博客
07-05 640
近1年，偶尔发生应用系统启动时某些操作超时的问题，特别在使用4核心Surface以后。笔记本和台式机比较少遇到，服务器则基本上没有遇到过。 这些年，我写的应用都有一个习惯，就是启动时异步做很多准备工作。基本上确定这个问题跟它们有关。 最近两个月花了些时间分析线程池调度机制，有点绕，这里记录下来，防止以后忘了。 （文章很长，时间不多的同学可以直接看最后！）    一、现象 这里以一个典型...
topic.metadata.refresh.interval.ms
Just do IT.
03-30 1484
The producer generally refreshes the topic metadata from brokers when there is a failure (partition missing, leader not available…). It will also poll regularly (default: every 10min so 600000ms).
跟我一起学【Hive】之——静态分区、动态分区
SunWuKong_Hadoop的博客
12-28 495
虽然之前已经用过很多次hive的分区表，但是还是找时间快速回顾总结一下加深理解. 举个栗子，基本需求就是Hive有一张非常详细的原子数据表original_device_open，而且还在不断随着时间增长，那么我需要给它进行分区，为什么要分区?因为我想缩小查询范围，提高速度和性能. 分区其实是物理上对hdfs不同目录进行数据的load操作，0.7之后的版本都会自动创建不存在的hdfs的目录，不...
Hive调优参数配置
weixin_30237719的博客
06-07 245
Hive进行大数据处理的过程中经常遇到一个任务跑几个小时或者内存溢出等问题，平时会任务执行的遇到的问题 进行参数的调整配置，收集整理的配置参考如下： set dfs.namenode.handler.count=20; set mapred.task.timeout=36000000; set hive.cbo.enable=true; set hive.compute.query....
解析ActivityManagerService
热门推荐
lixiong0713的博客
07-13 2万+
解析ActivityManagerService Android 系统启动过程、应用程序进程启动过程以及四大组件工作过程，都涉及了 ActivityManagerService（以后简称AMS），本文将基于Android8.1.0系统来对AMS进行讲解。 1. AMS 的启动过程 要想更好地理解 AMS ，很有必要了解 AMS 的启动过程， AMS 的启动是在 SystemServer进程中启动的，关于 SystemServer 进程的启动过程在“Andro...
某个牛人做WINDOWS系统文件详解
08-23 1009
某个牛人做WINDOWS系统文件详解。超牛!很详细介绍WINDOWS系统文件用途,想各位保存一份以后说定会有用A　↑ ACCESS.CHM - Windows帮助文件 ACCSTAT.EXE - 辅助状态指示器 ADVAPI32.DLL - 高级Win32应用程序接口 AHA154X.MPD - SCSI驱动程序 AM1500T.VXT - 网卡驱动程序 AM2100.DOS - 网卡驱动
live555 RTSP服务器与客户端通信源码分析
C++ 开发者的博客
11-24 2230
本文主要介绍了live555 服务器与客户端的通信流程，使用的版本为2019.8.28日
Android消息机制不完全解析（下）
a220315410的专栏
08-29 3850
接着上一篇文章Android消息机制不完全解析（上），接着看C++部分的实现。
第一关kafka-初体验
最新发布
12-01
bin/kafka-topics.sh --create --topic test --bootstrap-server localhost:9092 ``` 4. 发送一些消息 ```shell bin/kafka-console-producer.sh --topic test --bootstrap-server localhost:9092 >Hello, ...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值