Question

我有一个3节点的Zookeeper集群版本3.4.11和2节点的Kafka集群版本0.11.3。我们编写了一个生产者，该生产者将消息发送到Kafka集群的特定主题和分区（我之前做过，并且对该生产者进行了测试）。这是Brokers配置：

broker.id=1
listeners=PLAINTEXT://node1:9092
num.partitions=24
delete.topic.enable=true
default.replication.factor=2
log.dirs=/data
zookeeper.connect=zoo1:2181,zoo2:2181,zoo3:2181
log.retention.hours=168
zookeeper.session.timeout.ms=40000
zookeeper.connection.timeout.ms=10000
offsets.topic.replication.factor=2
transaction.state.log.replication.factor=2
transaction.state.log.min.isr=2

在开始时，代理上没有主题，它们将自动创建。当我启动生产者时，Kafka群集显示出奇怪的行为：

1-它创建所有主题，但是虽然数据生成速度为每秒10KB，但在不到一分钟的时间内，每个代理的日志目录从零数据变为9.0 GB数据！并且所有经纪人都关闭了（由于缺少日志目录容量）

2-刚开始生成数据时，我尝试使用console-consumer消费数据，但这只是错误

WARN Error while fetching metadata with correlation id 2 : {Topic1=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)

3-这是在代理日志中反复出现的错误：

INFO Updated PartitionLeaderEpoch. New: {epoch:0, offset:0}, Current: {epoch:-1, offset-1} for Partition: Topic6-6. Cache now contains 0 entries. (kafka.server.epoch.LeaderEpochFileCache)
WARN Newly rolled segment file 00000000000000000000.log already exists; deleting it first (kafka.log.Log)
WARN Newly rolled segment file 00000000000000000000.index already exists; deleting it first (kafka.log.Log)
WARN Newly rolled segment file 00000000000000000000.timeindex already exists; deleting it first (kafka.log.Log)
ERROR [Replica Manager on Broker 1]: Error processing append operation on partition Topic6-6 (kafka.server.ReplicaManager)
kafka.common.KafkaException: Trying to roll a new log segment for topic partition Topic6-6 with start offset 0 while it already exists.

在重复以上日志之后，我们得到了：

ERROR [ReplicaManager broker=1] Error processing append operation on partition Topic24-10 (kafka.server.ReplicaManager)
org.apache.kafka.common.errors.InvalidOffsetException: Attempt to append an offset (402) to position 5 no larger than the last offset appended (402)

最后（当log-dir中没有空间时）会出错：

FATAL [Replica Manager on Broker 1]: Error writing to highwatermark file:  (kafka.server.ReplicaManager)
java.io.FileNotFoundException: /data/replication-offset-checkpoint.tmp (No space left on device)

然后关闭！

4-我又在另一台计算机上设置了新的单节点Kafka版本0.11.3，并且在使用相同的生产者和相同的Zookeeper集群的情况下，它都能很好地工作。

5-我关闭了两个Kafka代理之一，而仅使用了（集群中的）一个代理，其行为与我使用两个节点Kafka集群时的行为相同。

出什么问题了？

UPDATE1：：我尝试了Kafka 2.1.0版，但结果相同！

UPDATE2：我发现了问题的根源。在制作过程中，我创建了25个主题，每个主题都有24个分区。令人惊讶的是，每个主题在创建后（使用kafka-topic.sh命令并且没有存储数据时）占用481MB的空间！例如，在每个分区目录的主题“ 20”的日志目录中，我有以下文件，总共有21MB：

00000000000000000000.index (10MB)  00000000000000000000.log(0MB)  00000000000000000000.timeindex(10MB)  leader-epoch-checkpoint(4KB)

Kafka为server.log文件中的每个主题分区写以下行：

[2019-02-05 10:10:54,957] INFO [Log partition=topic20-14, dir=/data] Loading producer state till offset 0 with message format version 2 (kafka.log.Log)
[2019-02-05 10:10:54,957] INFO [Log partition=topic20-14, dir=/data] Completed load of log with 1 segments, log start offset 0 and log end offset 0 in 1 ms (kafka.log.Log)
[2019-02-05 10:10:54,958] INFO Created log for partition topic20-14 in /data with properties {compression.type -> producer, message.format.version -> 2.1-IV2, file.delete.delay.ms -> 60000, max.message.bytes -> 1000012, min.compaction.lag.ms -> 0, message.timestamp.type -> CreateTime, message.downconversion.enable -> true, min.insync.replicas -> 1, segment.jitter.ms -> 0, preallocate -> false, min.cleanable.dirty.ratio -> 0.5, index.interval.bytes -> 4096, unclean.leader.election.enable -> false, retention.bytes -> -1, delete.retention.ms -> 86400000, cleanup.policy -> [delete], flush.ms -> 9223372036854775807, segment.ms -> 604800000, segment.bytes -> 1073741824, retention.ms -> 604800000, message.timestamp.difference.max.ms -> 9223372036854775807, segment.index.bytes -> 10485760, flush.messages -> 9223372036854775807}. (kafka.log.LogManager)
[2019-02-05 10:10:54,958] INFO [Partition topic20-14 broker=0] No checkpointed highwatermark is found for partition topic20-14 (kafka.cluster.Partition)
[2019-02-05 10:10:54,958] INFO Replica loaded for partition topic20-14 with initial high watermark 0 (kafka.cluster.Replica)
[2019-02-05 10:10:54,958] INFO [Partition topic20-14 broker=0] topic20-14 starts at Leader Epoch 0 from offset 0. Previous Leader Epoch was: -1 (kafka.cluster.Partition)

服务器日志上没有错误。如果我生成有关该主题的数据，我什至可以使用数据。由于日志总目录空间为10GB，在我的方案中，Kafka需要2525个主题才能使用12025MB，这比目录空间总和还要大，Kafka会出错并关机！

为了进行测试，我使用相同的Zookeeper集群设置了另一个Kafka代理（即broker2），并创建了一个具有24个分区的新主题，那里所有空分区仅占用了10万个！

所以我真的很困惑！相同版本的Kafka（0.11.3）的Broker1和Broker2，正在运行，只是操作系统和系统文件不同：

如果是Broker1（新主题占用481MB数据）：

OS CentOS 7和XFS作为系统文件

如果Broker2（一个新主题占用100KB数据）：

操作系统Ubuntu 16.04和ext4作为系统文件

Answer 1

为什么Kafka为每个分区预分配21MB？

这是正常现象，使用服务器属性segment.index.bytes控制索引的预分配大小，默认值为10485760字节或10MB。这是因为每个分区目录中的索引分配了10MB：

00000000000000000000.index (10MB)  
00000000000000000000.log(0MB)  
00000000000000000000.timeindex(10MB)  
leader-epoch-checkpoint(4KB)

另一方面，Kafka文档中说明了该属性：

We preallocate this index file and shrink it only after log rolls.

但就我而言，它从未缩水索引。经过大量搜索后，我发现某些版本的Java 8（在我的情况下为192）在处理许多小文件时存在错误，并且已在更新202中修复。因此，我将Java版本更新为202，并解决了问题。 / p>

Kafka在创建新主题时会产生大量额外数据

1 个答案: