今天同事发现创建 kafka 的时候出现错误
|
|
解决这个问题首先需要判断问题出错的地方
首先定位是否 kafka 的集群不健康，检查所有日志。发现 kafka 中会报错 kafka 的 host not found。重启直到 kafka 成功不报错。
第二步解决报错的日志，这次报错的日志是
WARN [ReplicaFetcher replicaId=2, leaderId=0, fetcherId=0] Received INCONSISTENT_TOPIC_ID from the leader for partition test-1. This error may be returned transiently when the partition is being created or deleted, but it is not expected to persist. (kafka.server.ReplicaFetcherThread) 删除掉这个 topic。 删除命令行
|
|
删除 topic，但是继续进行自动创建 kafka 的命令
|
|
但是依然报错 选择手动进行 kafka 的 topic 创建
|
|
发现这种情况下，可以正常进行。 那么问题应该出现在自动化创建 topic 的设置问题，重新查看 kafka 的配置文件，发现是 kafka 的自动创建 topic 被关闭了
|
|
设置为 true 时，可以支持自动创建了。
Topic 在 Kafka 中是主题的意思，生产者将消息发送到主题，消费者再订阅相关的主题，并从主题上拉取消息。
在创建 Topic 的时候，有两个参数是需要填写的，那就是 partions 和 replication-factor。
partions
主题分区数。kafka 通过分区策略，将不同的分区分配在一个集群中的 broker 上，一般会分散在不同的 broker 上，当只有一个 broker 时，所有的分区就只分配到该 Broker 上。
消息会通过负载均衡发布到不同的分区上，消费者会监测偏移量来获取哪个分区有新数据，从而从该分区上拉取消息数据。
分区数越多，在一定程度上会提升消息处理的吞吐量，因为 kafka 是基于文件进行读写，因此也需要打开更多的文件句柄，也会增加一定的性能开销。
如果分区过多，那么日志分段也会很多，写的时候由于是批量写，其实就会变成随机写了，随机 I/O 这个时候对性能影响很大。所以一般来说 Kafka 不能有太多的 Partition。
下图设置 topic-1 的 partions 为 3，会自动分配在不同的 broker 上，采用均匀分配策略，当 broker 和 partions 一样时，就均匀分布在不同的 broker 上。
replication-factor
用来设置主题的副本数。每个主题可以有多个副本，副本位于集群中不同的 broker 上，也就是说副本的数量不能超过 broker 的数量，否则创建主题时会失败。
比如 partions 设置为 20，replicationFactor 设置为 1. Broker 为 2.可以看出，分区会均匀在 broker
上进行分配。