Kafka系列文章:
Kafka系列 —— 入门及应用场景 & 部署 & 简单测试
topic & partition & replication
bin/kafka-topics.sh --create \
--zookeeper 192.168.137.141:2181,192.168.137.142:2181,192.168.137.143:2181/kafka \
--replication-factor 3 --partitions 3 --topic ruozedata
针对上述创建topic的命令,进行解读:
- topic
主题,可以理解为文件夹,每个文件夹专门存放某一类数据
不同的主题针对于不同的业务线 - partition
分区, 根据创建topic的命令可以看见有3个分区
会将topic里的数据给拆分到不同的分区里面
每台机器的 /opt/software/kafka/logs 目录下,都会有对应的3个分区:
注意: 下标是从0开始的
以ruozedata-0这个分区为例,里面的内容如下(每个分区中的结构其实是一样的):
log存放数据(log大小为0是因为还没有往里写数据),index存放索引
因此我们也可以发现Kafka的数据是落在磁盘上的(是物理上的分区),默认是保留7天 - replication
副本,根据创建topic的命令可以看见有3个副本
指的是一个分区被复制3份
二维图,感官性的认识:
leader & replicas & Isr & broker
第一行列举出了topic的名称、分区数、副本数
Partition:0 & Partition:1 & Partition:2 分别对应 ruozedata-0 & ruozedata-1 & ruozedata-2
- leader
Leader:1指的是broker.id=1,即第一台机器作为partition 0的leader
后面的解释以此类推
负责读和写,读和写都是leader来干的(和传统的不同,比如MySQL主节点负责写,从节点负责读) - Replicas
指的是对应partition的副本分布在哪几台机器上
复制该分区数据的节点列表,第一位数字代表的是leader ----- 静态表述 - Isr
in-sync Replicas 正在复制的副本节点列表 ------------------------ 动态表述
当leader挂了,会从这个列表选举出新的leader
通过实验加深印象,去hadoop003机器上干掉Kafka进程,再查看:
Replicas代表的是partition的副本理应分在哪几台机器上
Isr代表的是正在将这些partition的副本给同步(或复制)到对应的机器上,但是在这个in-sync的过程中Kafka进程可能会挂,因此我们可以发现当我们kill hadoop003的kafka进程时,Isr上都少了3,而对于Partition:2,由于原来作为leader的机器上的kafka进程挂了,因此会在剩余的机器中选举出新的作为leader - broker
代表的是每台机器上面运行的Kafka的实例,说白了就是kafka的进程
从上述关于Kafka部署的章节中我们可以发现,Kafka只有一个进程,该进程就是broker,用于存储,至于生产者和消费者是其它组件做的事情
(重要)关于partition的思考
问题: 1个topic为什么要分割成多个partition?
思考: 1个topic向1个文件去读,和向10个文件去读,谁的效率高呢?
个人经验总结:
–replication-factor 3
–partitions 数量会取决于你的broker数量,也就是说取决于装了几台Kafka
生产上的参数:
–replication-factor 3 --partitions 8
设置成8个partition的原因:
- Kafka机器8个,设置成8个,满满的,一个都不浪费
- 结合Spark官网:
在direct模式下,Kafka的partition和Spark的partition是1:1的关系
因此当我们将Kafka的partition设置成8个的时候,Spark Streaming去消费的时候
读进来之后,Spark partition也为8个,因此并行度也就高了
调优的手段
适当的partition:
虽然我们增加了分区数,提高了Kafka写和读的吞吐量,但是如果过多的分区数未必好
1个集群有多个topic,必然是有多个分区,那么对于1台机器上也是会有多个topic的分区,如:ruozedata-0 、test-0、jepson-0等等(不同的topic的partition)
当我们的计算程序来进行读取的时候,linux打开文件的句柄也就需要的更多了,就需要更多的文件数、进程数,那就需要去调优了
建议:一个集群上不要有过多的topic
producer & consumer & consumer group & offset
- producer
生产者,常见的有:flume/maxwell - consumer
消费者,常见的有:Spark Streaming/flink
正常的架构:producer —> broker —> consumer(broker即我们部署的kafka)
- consumer group
正常在企业中用的不是很多
1个消费组可以包含1个或多个消费者,分区只能被1个消费组的其中1个消费者去消费
3个partition落在3台机器上,消费情况如下(图助于理解概念):
正常在企业开发使用多分区方式去提高计算的能力 - offset
偏移量:消费时读取一个分区的文件的数据,数据所在下标
后续在讲语义分析的时候会重度剖析
(重要)关于分区是否有序的思考
- 对于单个分区来说,读的数据是否有序? ==> 有序
- 对于多个分区来说,读的数据是否有序? ==> 无序
无序该怎么解决?生产上没有解决 困扰!!