跟我学Kafka:如何高效运维之主题篇
Posted 中间件兴趣圈
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了跟我学Kafka:如何高效运维之主题篇相关的知识,希望对你有一定的参考价值。
摘要:对Kafka-topics命令详解,并从运维角度窥探Kafka关于topic的运作机制。
作为一个Kafka初学者,需要快速成长,承担维护公司Kafka的重任,对Kafka的学习,我按照三步走策略:
- 阅读Kafka相关书籍
- 从运维实战的角度学习Kafka
- 阅读源码,体系化,精细化掌握其实现原理
本文属于学习的第二阶段:[从运维实战的角度学习Kafka],本文重点学习Kafka的主题,如何通过运维命令创建、更新主题,从Topic的可运维属性,了解Topic在Kafka内部的运作机制。
1、Kafka topic运维命令的基本使用
Kafka提供了kafka-topics脚步用来创建、修改、删除、查询topic,位于${kafka_home}/bin/kafka-topics.sh,其中kafka_home表示Kafka的安装目录。
选项 | 类型 | 详细说明 |
---|---|---|
–create | 命令 | 创建Topic |
–delete | 命令 | 删除Topic |
–alter | 命令 | 修改Topic |
–describe | 命令 | 查看Topic |
–delete-config | 命令 | 删除topic配置的属性 |
–list | 命令 | 查询topic列表 |
–bootstrap-server | 选项 | 指定kafka集群的地址 |
–zookeeper | 选项 | zk集群的地址,与–bootstrap-server选项必须有一个不能为空 |
–partitions | 选项 | Topic的分区数量,可以认为是数据分片的份额,每一个分区还可以有多个副本。 |
–replication-factor | 选项 | 分区的副本因子(包含Leader个数) |
–topic | 选项 | 主题的名称 |
–if-exists | 选项 | 在修改或删除topic时,如果指定该选项,只有在存在时才执行 |
–if-not-exists | 选项 | 在创建topic时,如果指定该选项,只有在topic不存在时才执行 |
–replica-assignment | 选项 | 收到指定分区与副本,官方文档看起来比较负责,下文详细介绍。 |
–disable-rack-aware | 选项 | 禁止机架感知副本分配 |
–exclude-internal | 选项 | 在使用–list命令查询主题时过滤内部权限 |
–topics-with-overrides | 选项 | 使用–describe只显示topic相关的属性,分区信息不显示。 |
–unavailable-partitions | 选项 | 使用–describe只显示Leader不可用的分区,如有输出信息,需要关注。 |
–under-replicated-partitions | 选项 | 使用–describe只显示有副本不在ISR的分区信息,如有输出信息,需要关注。 |
–config | 选项 | 设置topic的属性 |
接下来对一些上述一些不那么直观的选项进行单独介绍。
1.1 --replica-assignment
收到指定副本数量和分区信息,该参数不能和–partitions、–replication-factor同时使用。
其格式为:每一个逗号表示一个分区的配置,每一个分区分布的broker用冒号隔开。
–replication-factor 0:1,1:2,0:2 表示的含义是什么呢?
分区数量为3个,其中分区0(p0)分布在broker 0和1上,分区1(p1)分布在broker 1,2上,分区2(p2)分布在broker 0与1上。从而推出分区数量为3,副本因子为2,每一个分区的第一个broker为Leader,其演示效果如下:
2、Kafka Topic配置项详解
通过kafka-topics脚本在创建topic时可通过–config选项来定制化topic的属性,接下来试图从这些属性来探究Kafka背后的运作机制。
-
cleanup.policy
数据文件清除机制,支持Broker全局配置,Topic定制化制定,可选策略:delete、compact,默认值为delete。Kafka提供了数据段压缩的功能,按照相同Key只保留最新Key的策略,减少数据段大小,系统主题__consumer_offsets(用于存储消息进度的主题)其清除策略就是compact。 -
compression.type
压缩类型,Kafka目前支持的压缩算法:gzip,snappy,lz4,zstd,还支持如下两个配置:- uncompressed
不开启压缩 - producer
由发送方指定压缩算法,客户端的可选值为gzip,snappy,lz4,zstd。
数据进行压缩,能节省网络带宽与存储空间,但会增加CPU的性能,故最佳实践:Broker服务端不配置压缩算法,由发送方指定,在发送方进行压缩,服务端原封不动进行存储,并且在消费端解压缩。
- uncompressed
-
delete.retention.ms
如果cleanup.policy策略为compact时,针对消息体为null的消息,Kafka会认为对其进行压缩没有意义,立马删除也太草率,故Kafka引入了该参数,用来设置这些body为null的消息,在一次压缩执行后,多久后可被删除,默认值为24h。 -
file.delete.delay.ms
文件在删除时延迟时间,默认为60s,Kafka中可以支持按topic删除日志文件(数据文件),执行删除之前,首先会将该topic下的分区文件重名为*.deleted,等待file.delete.delay.ms才从文件系统中删除。
-
flush.messages
按消息条数设置刷盘频率,如果设置为1表示每写一条消息就触发一次刷盘,默认值为Long.MaxValue,在大部分场景官方不建议设置该值,直接利用操作系统的刷盘机制即可,Kafka希望通过副本机制能保证数据的持久可靠存储。 -
flush.ms
按时间间隔设置刷盘频率,默认为Long.MaxValue,Kafka希望借助操作系统的刷盘机制,数据可靠性通过副本机制来保证。(副本机制其实无法保证同机房断电带来的数据丢失) -
index.interval.bytes
索引文件的密度,Kafka并不会为每一条消息(消息偏移量)建立索引,而是每隔一定间隔,建立一条索引。该参数就是设置其间隔,默认为4096个字节。 -
max.message.bytes
一次消息发送(Batch)允许的最大字节数量,默认为1000000,约等于1M。 -
message.downconversion.enable
是否开启消息格式的自动转化,如果设置为false,Broker不会执行消息格式转化,将不兼容老的客户端消费消息。 -
message.format.version
可以指定该主题按特定版本的API版本所对应的存储格式进行存储。 -
message.timestamp.type
设置消息中存储的时间戳的获取方式,可选值:- CreateTime
消息在客户端的创建时间 - LogAppendTime
Broker服务端接收到的时间
默认为CreateTime。
- CreateTime
-
message.timestamp.difference.max.ms
当message.timestamp.type设置为CreateTime时,允许Broker端时间与消息创建时间戳最大的差值,如果超过该参数设置的阔值,Broker会拒绝存储该消息,默认为:Long.MaxValue,表示不开启开机制。 -
min.cleanable.dirty.ratio
控制可压缩的脏数据比例,默认为0.5d,如果一个文件中"脏数据"(未被压缩的数据)低于该阔值,将不继续对该文件进行压缩,该方法生效的条件为cleanup.policy设置为compact。 -
min.compaction.lag.ms
设置一条消息进入到Broker后多久之内不能被compact,默认为0,表示不启用该特性,该方法生效的条件为cleanup.policy设置为compact。 -
min.insync.replicas
如果客户端在消息发送时将ack设置为all,该参数指定必须至少多少个副本写入成功,才能向客户端返回成功,默认为1,这个是一个兜底配置,all的含义表示在ISR中的副本必须全部写入成功。 -
preallocate
是否开启预热文件(提前创建文件),默认为false。 -
retention.bytes
一个日志分区保留的最大字节数,默认为-1,表示不限制。 -
retention.ms
一个日志分区允许保留的最大时长,默认保留7d。 -
segment.bytes
一个日志段的大小,默认为1G。 -
segment.index.bytes
一个日志段索引文件的大小,默认为10M。 -
segment.jitter.ms
段滚动的最大随机差。 -
segment.ms
Kafka强制滚动一个段的间隔时间,及时该段并未全部填满消息,默认值为7d -
unclean.leader.election.enable
是否允许不在ISR中副本在没有ISR副本选择之后竞争成为Leader,这样做有可能丢数据,默认为false。
3、总结
本文从运维命令开始学习,从使用运维层面全面了解Topic,从而窥探其Kafka内部一些重要特性,为后续从源码角度研究其实现打下坚实基础,本文的最后给出一个分区数量为3,副本因子为3的topic分区图来结束本文的讲解。
好了,本文就介绍到这里了,一键三连(关注、点赞、留言)是对我最大的鼓励。
掌握一到两门java主流中间件,是敲开BAT等大厂必备的技能,送给大家一个Java中间件学习路线,助力大家实现职场的蜕变。
最后分享笔者一个硬核的RocketMQ电子书,您将获得千亿级消息流转的运维经验。
获取方式:私信回复 RMQPDF 即可获得。
以上是关于跟我学Kafka:如何高效运维之主题篇的主要内容,如果未能解决你的问题,请参考以下文章