跟我学Kafka：如何高效运维之主题篇

作为一个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与2上。从而推出分区数量为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服务端不配置压缩算法，由发送方指定，在发送方进行压缩，服务端原封不动进行存储，并且在消费端解压缩。
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。
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分区图来结束本文的讲解。

好了，本文就介绍到这里了，键三连(关注、点赞、留言)是对我最大的鼓励，当然可以加笔者微信：dingwpmz，共同交流探讨。

最后分享笔者一个硬核的RocketMQ电子书，您将获得千亿级消息流转的运维经验。

获取方式：微信搜索【中间件兴趣圈】，回复RMQPDF即可获取。

走进作者

我的另一种参与 RocketMQ 开源社区的方式