该文档对应的是 kafka安装目录/config/server.properties 文件中的topic部份的内容。由于原英文版的文档从句太多太难理解,我花了四天时间翻译了一份中文文档,希望给大家带来帮助,有问题请留言。
可能网页显示不全,请下载附件PDF。
名称 |
描述 |
类型 |
默认值 |
可用值 |
服务器默认属性 |
重要性 |
cleanup.policy |
"delete" 或 “compact”的字符串。这个字符串指派了用在老的日志片段的保存策略。默认的策略(“delete”)会在它们的保留时间或是大小超出限制时丢弃老的片段。设置为”compact”将在主题上启用日志压缩。 |
列表 |
delete |
[compact, delete] |
log.cleanup.policy |
中 |
compression.type |
为一个给定的主题指定最终的压缩类型。这个配置接受标准的压缩编码器('gzip', 'snappy', lz4)。它额外的接受’uncompressed’,等于不压缩;还有'producer' 表示使用生产者设置的原始压缩编码器。 |
字符 |
producer |
[uncompressed, snappy, lz4, gzip, producer] |
compression.type |
中 |
delete.retention.ms |
为日志压缩主题保留删除墓碑标记的时间。这个设置也给出了一个消费者必须完成一个读取的边界,如果它们开始从偏移0 到确保它可以得到一个可用的最尾端的快照(否则在它们完成扫描之前删除墓碑会被收集) |
长整型 |
86400000 |
[0,...] |
log.cleaner.delete.retention.ms |
中 |
file.delete.delay.ms |
从文件系统删除一个文件之前的等待时间。 |
长整型 |
60000 |
[0,...] |
log.segment.delete.delay.ms |
中 |
flush.messages |
这个设置允许指定一个时间间隔,它将用于写入到日志的数据强制进行文件同步。例如:如果这个值被设置为1我们将在每条消息之后进行文件同步。如果是5我将在每5条消息后进行文件同步。通常我们推荐你不要设置这个值并使用副本实现持久性和允许使用操作系统的后台刷新能力,因为它更高效。此设置可以按每个主题覆盖(参见每个主题配置部分)。 |
长整型 |
9223372036854775807 |
[0,...] |
log.flush.interval.messages |
中 |
flush.ms |
这个设置允许指定一个时间间隔,它将用于写入到日志的数据强制进行文件同步。例如:如果这个值被设置成1000我们将在1000毫秒之后进行文件同步。通常我们推荐你不要设置这个值并使用副本实现持久性和允许使用操作系统的后台刷新能力,因为它更高效。 |
长整型 |
9223372036854775807 |
[0,...] |
log.flush.interval.ms |
中 |
follower.replication.throttled.replicas |
应该被限制在跟随者端的日志副本列表。这个列表应该描述成副本的一个集合,格式为 [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:…或是可选的通配符“*”,可以用来限制这个主题的所有副本。 |
列表 |
"" |
[partitionId],[brokerId]:[partitionId],[brokerId]:... |
follower.replication.throttled.replicas |
中 |
index.interval.bytes |
这个设置控制了 Kafka添加一个索引入口到它的偏移索引的频率。默认设置是确保我们的索引信息大约每4096字节。更多的索引允许在日志中读取时跳跃到离期望的位置更近的地方,但是这样会让索引更大。你很可能不需要更改这个值。 |
列表 |
4096 |
[0,...] |
log.index.interval.bytes |
中 |
leader.replication.throttled.replicas |
应该被限制在服务器端的日志副本列表。这个列表应该描述成副本的一个集合,格式为 [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:…或是可选的通配符“*”,可以用来限制这个主题的所有副本。 |
列表 |
"" |
[partitionId],[brokerId]:[partitionId],[brokerId]:... |
leader.replication.throttled.replicas |
中 |
max.message.bytes |
Kafka允许的最大的记录批次大小。如果这是增长的并且有老于0.10.2的消费者,消费者获取大小也必须是增长的以便它们可以这个大小的记录批次。在最新的消息格式版本中,记录常常分组为批次来实现更高效。在先前的消息格式版本中,未压缩的记录没有按批次分组,并且在这种情况下这样的局限仅适用于一个单一的记录。 |
整型 |
1000012 |
[0,...] |
message.max.bytes |
中 |
message.format.version |
指定了broker将用于追加消息到日志的消息格式的版本。这个值应该是一个有效的API版本。例如:0.8.2, 0.9.0.0, 0.10.0,更多详情请查看API版本。通过设置一个独特的消息格式版本,用户可以证明所有在磁盘上已存在的消息版本都小或等于指定版本。如果这个值没有被正确的设置将导致有更老版本的消费者崩溃,它们将收到带有一个它们不认识的格式的消息。 |
字符 |
0.11.0-IV2 |
|
log.message.format.version |
中 |
message.timestamp.difference.max.ms |
一个broker收到一个消息时的时间戳与在消息中指定的时间戳之间允许的最大差异。如果message.timestamp.type=CreateTime,消息会被拒绝,如果时间戳的差异超过了这个阈值。如果message.timestamp.type=LogAppendTime这个配置会被忽略。 |
长整型 |
9223372036854775807 |
[0,...] |
log.message.timestamp.difference.max.ms |
中 |
message.timestamp.type |
定义消息的时间戳是消息的创建时间或是日志的追加时间。这个值应该是`CreateTime` 或 `LogAppendTime` |
字符 |
CreateTime |
|
log.message.timestamp.type |
中 |
min.cleanable.dirty.ratio |
这个配置控制着日志压缩器将要尝试清理日志的频率(假设日志压缩已启用)。默认情况下,我们将避免清理超过50%的已被压缩的日志。这个比率限制了日志中重复的最大空间(最多50%个日志中的50%个可能是重复的)。更高的比率意味着更少、更高效的清洁,但也意味着在日志中有更多的空间浪费。 |
双精度型 |
0.5 |
[0,...,1] |
log.cleaner.min.cleanable.ratio |
中 |
min.compaction.lag.ms |
一条消息在日志里保持未压缩的最小时间。只对压缩的日志有效。 |
长整型 |
0 |
[0,...] |
log.cleaner.min.compaction.lag.ms |
中 |
min.insync.replicas |
当一个生产者设置acks 为 “all”或是 “-1”。这个配置指定了必须被认为是成功的一个写入的副本的最小数量。如果这个最小数量不能被满足,那么生产者将抛出一个异常( NotEnoughReplicas 或 NotEnoughReplicasAfterAppend)。当min.insync.replicas 和 acks 一起使用时,允许你实现更强的耐久性保证。一个典型的情况是与3个复制因子创建主题,设置 min.insync.replicas 为2,并且生产者的acks 为 “all”。这将确保生产者抛出一个意外,如果一个主要的副本没有接收到一个写入。 |
整型 |
1 |
[1,...] |
min.insync.replicas |
中 |
preallocate |
设为true时我们应当在创建一个新的日志片段时预分配文件在磁盘上。 |
布尔 |
FALSE |
|
log.preallocate |
中 |
retention.bytes |
如果我们使用”delete”保留策略,这个配置控制了丢弃一个老的日志片段来释放之前保留一个日志文件可以增长到的最大在小。默认情况下没有大小限制,只有时间限制。 |
长整型 |
-1 |
|
log.retention.bytes |
中 |
retention.ms |
如果我们使用”delete”保留策略,这个配置控制了丢弃一个老的日志片段来释放之前保留一个日志文件最大时间。这代表在服务级别协议之上,一个消费者必须多快地读取他们的数据。 |
长整型 |
604800000 |
|
log.retention.ms |
中 |
segment.bytes |
这个配置控制了日志片段文件。保留或清理通常是一次一个文件的进行的。所以一个大的片段大小意味着更少的文件,但是保留上的控制会有更少的颗粒。 |
整型 |
1073741824 |
[14,...] |
log.segment.bytes |
中 |
segment.index.bytes |
这个配置控制了到文件位置的映射偏移索引的大小。我们预分配这个索引文件并且只在日志展开后收缩。通常情况下不需要改这个设置。 |
整型 |
10485760 |
[0,...] |
log.index.size.max.bytes |
中 |
segment.jitter.ms |
计划的片段展开时间减少的最大随机抖动,以免发生迅速集中的片段展开。 |
长整型 |
0 |
[0,...] |
log.roll.jitter.ms |
中 |
segment.ms |
这个配置控置了时间周期,在这之后 kafka将会强制日志展开,即使这个片段文件没有满到确保保留可以删除或是压缩旧的数据。 |
长整型 |
604800000 |
[0,...] |
log.roll.ms |
中 |
unclean.leader.election.enable |
指示是否开启不在ISR里的副本设置为选举为领导者作为最后的手段,尽管这样做会导致数据丢失。 |
布尔 |
FALSE |
|
unclean.leader.election.enable |
中 |
相关推荐
本文将详细介绍Kafka的参数配置,包括系统参数、Topic参数、ZooKeeper参数和日志参数。 系统参数 在Kafka集群中,每个 broker 节点都需要一个唯一的标识符,称为 broker.id。这个参数的值必须是一个正数。在这个...
Kafka的Topic可以通过配置参数调整,如保留消息的时间(`retention.ms`)、分区的偏移量保存策略等。这些配置可以通过`--alter`选项动态修改。 **安全模式下的Topic管理** 在Kafka企业环境中,可能需要启用SASL或...
本篇将深入探讨Kafka配置参数,帮助你理解和优化Kafka集群的运行。 1. **broker.id**: 这个参数是每个Kafka broker的唯一标识,它必须在整个集群中是唯一的。值可以是任意整数,通常从0开始。 2. **zookeeper....
* 在挂载块设备时,加上 noatime 参数,该参数在文件被读取时不会更新文件访问时间,kafka 不依赖该时间,使用这个参数可以减少读文件开销。 * 不要将 kafka 的日志和其他应用日志与 kafka 的数据盘放在一起,让数据...
在大数据处理领域,Apache Kafka是一个不可或缺的组件,它作为一个...在实际部署过程中,根据具体的业务需求和环境,可能还需要调整其他配置参数。了解并熟练掌握这些配置对于高效、稳定地运行Kafka集群至关重要。
在实际使用过程中,需要对Kafka的配置参数进行详细理解,以便根据具体业务需求调整参数,优化性能。以下对Kafka主要配置参数进行详细解读: 1. broker.id:这是Kafka broker的唯一标识符,它是一个整数,用于唯一...
这里我们关注的焦点是 Kafka 的配置文件,包括 `server.properties`、`consumer.properties` 和 `producer.properties`,它们对于理解和优化 Kafka 集群的运行至关重要。 首先,我们来看 `server.properties` 文件...
在Kafka的运行中,`server.properties`是每个Kafka broker节点的核心配置文件,它定义了服务器的行为和参数。下面将详细解释`server.properties`中的关键配置项: 1. **broker.id**: 每个Kafka节点都有一个唯一的ID...
本文将详细解析如何在处理大文件时,优化Kafka的配置参数,确保高效、稳定地进行数据生产和消费。 首先,我们要了解Kafka的核心组件:生产者(Producer)和消费者(Consumer)。生产者负责将数据写入Kafka的主题...
【正文】 Kafka是一款高效的消息中间件,常用于大数据实时处理和流计算场景。本篇文档将详细介绍如何在Linux环境中搭建Kafka集群,同时结合...同时,通过合理配置参数,可以优化Kafka的性能,满足不同业务场景的需求。
在配置方面,文档详细解析了Kafka集群的设置,如broker配置、日志管理、网络参数等,帮助管理员优化Kafka的性能和稳定性。此外,还涵盖了如何配置生产者和消费者,确保高效的数据传输和消费。 文档中还涵盖了Kafka...
在IT行业中,Apache Kafka是一个广泛使用的分布式流处理...在部署Kafka集群时,理解并适当地调整这些配置参数对于优化性能、保证数据安全性和提高可用性至关重要。对配置文件的深入了解是管理和维护Kafka集群的基础。
Kafka的配置主要集中在`server.properties`文件中,主要包括以下几个核心参数: - `broker.id`: 每个Kafka节点的唯一标识,从0开始。 - `zookeeper.connect`: 指定Zookeeper集群的连接字符串,格式为`ip1:port1,ip2...
### Kafka配置安装详解 #### 一、环境搭建与配置 Kafka是一款开源的消息队列中间件,被广泛应用于大数据处理领域。...在实际应用中,还需要根据具体需求进一步调整配置参数,以满足高性能、高可靠性的消息传输需求。
主题配置涉及到分区数量、副本因子等参数,如 `num.partitions`(分区数)、`replication.factor`(副本因子)等。 #### 3.3 Producer Configs 生产者配置主要包括消息发送策略、缓冲区大小等,如 `acks`(确认机制...
配置`config/server.properties`文件,包括设置broker.id、zookeeper.connect、log.dirs等参数。 4. **创建topics**:使用Kafka的管理命令行工具创建主题,例如,`bin/kafka-topics.sh --create --zookeeper ...
- **性能调优**:根据集群的实际运行情况调整相关配置参数,优化性能表现。 - **常见问题解答FAQ**:收集并整理常见的运维问题及解决方案,便于快速定位和解决问题。 ### 总结 Kafka作为一款优秀的分布式消息系统...
4. **创建主题**:允许用户创建新的主题,并设置相关的配置参数,如分区数、副本数、复制策略等。 5. **删除主题**:提供删除不再需要的主题的功能,但需谨慎操作,因为这将永久性地丢失该主题的所有数据。 6. **...
- **元数据管理**:Zookeeper用于存储Kafka集群的元数据信息,如Broker列表、Topic配置等。 - **协调服务**:Zookeeper还提供了高可用性的基础服务,如Leader选举、成员管理等。 #### 四、主要配置 Kafka的主要...