前文链接:
(一)Kafka0.8.2官方文档中文版系列-入门指南
(二)Kafka0.8.2官方文档中文版系列-API
Topic-level configuration(主题级别的参数配置)
与主题相关的配置具有全局默认值(参考broker部分)和每个主题可选重写(broker部分有明确提示)。如果主题没有重写这些配置,使用全局默认设置。可以使用--config添加一个或者多个自定义选项。下面这个例子创建了一个名为my-topic的主题,它自定义了最大消息大小和刷新速率:
> bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic my-topic --partitions 1 --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1
使用修改topic的命令可以修改修改之前设置的值。下面这个例子给出了如何更新最大消息大小的值:
> bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic my-topic --config max.message.bytes=128000
你可以这样删除自定义值(此时将会使用默认值)
> bin/kafka-topics.sh --zookeeper localhost:2181 --alter --topic my-topic --deleteConfig max.message.bytes
以下是主题级别的配置参数。
property | default | server default property | desrciption |
cleanup.policy | delete | log.cleanup.policy | 可以取值为delete或者compact。此字符串指定在旧日志段上使用的保留策略。当旧段的保留时间或大小限制达到时,默认策略("delete")将丢弃旧段。设置为"compact"将允许对主题进行日志压缩。 |
delete.retention.ms | 86400000 (24 hours) | log.cleaner.delete.retention.ms | 对于采用日志压缩的主题,即主题设置了log.cleanup.policy=compact,将保留已经被标注上删除标记的日志段的最大时间。消费者如果从偏移量的为0的地方开始读取,那么必须保证能够在这个时间内可以消费完数据。 |
flush.messages | None | log.flush.interval.messages | 此值允许我们强制将内存中的数据同步到log文件中(磁盘)。 例如,如果将其设置为1,我们将在每条消息之后进行fsync; 如果它是5,我们将在每5条消息后fsync。 通常,我们建议您不要设置此项,并使用复制来提高持久性,并允许操作系统的后台刷新功能,因为这更有效。 此值可以基于每个主题进行设置 |
flush.ms | None | log.flush.interval.ms | 此值允许我们强制将内存中的数据同步到log文件中(磁盘)。 例如,如果将其设置为1000,我们将在1000毫秒之后进行fsync; 通常,我们建议您不要设置此项,并使用复制来提高持久性,并允许操作系统的后台刷新功能,因为这更有效。 此值可以基于每个主题进行设置 |
index.interval.bytes | 4096 | log.index.interval.bytes | 此设置控制Kafka向其偏移索引添加索引条目的频率。 默认设置确保我们大约每4096个字节索引一条消息。 更多索引允许读取更接近日志中的确切位置,但使索引更大。 您可能不需要更改此设置。 |
max.message.bytes | 1,000,000 | message.max.bytes | 这是Kafka允许添加到topic的最大消息大小。需要注意的是,如果您增加了这个大小,您还必须增加您的消费者的获取大小,以便他们能够获取这么大的消息。 |
min.cleanable.dirty.ratio | 0.5 | log.cleaner.min.cleanable.ratio | 在开启了日志压缩的情况下,此配置控制日志压缩器尝试清理日志的频率。默认情况下,我们会避免去清理,已经压缩超过50%的日志。这个比率限制了日志中由于重复浪费的最大空间(最多50%的日志可以被重复)。更高的比率将意味着更少、更有效的清理,但将意味着日志中更多的浪费空间。 |
min.insync.replicas | 1 | min.insync.replicas | 当生产者设置request.required.acks=-1时,min.insync.replicas指定了必须确认写入的最小副本数量,以便被认为是成功的。如果没有达到这个值,生产者将会抛出异常(NotEnoughReplicas或者NotEnoughReplicasAfterAppend)。当min.insync.replicas和request.required.acks一起使用时,可以更好保证数据的安全耐用性。一个典型的应用例子就是,创建一个复制因子为3的主题,设置min.insync.replicas=2,request.required.acks=-1。这将保证如果大多数副本没有同步成功(这里就是2个副本),生产者会引发异常。 |
retention.bytes | None | log.retention.bytes | 如果使用“删除”保留策略,此配置将控制日志的最大大小,然后我们将丢弃旧的日志段以释放空间。默认情况下,没有大小限制,只有时间限制。 |
retention.ms | 7 days | log.retention.minutes | 如果使用“删除”策略,此配置将控制保留日志的最大时间,然后丢弃旧的日志段以释放空间。这代表了一种服务协议,消费者必须在指定的时间内消费它的数据。 |
segment.bytes | 1GB | log.segment.bytes | 此配置控制日志的段文件大小。保持和清理总是在完成一个日志文件段时进行,因此更大的段大小意味着更少的文件,同时更粗的粒度去执行保留策略。 |
segment.index.bytes | 10MB | log.index.size.max.bytes | 这个配置控制着索引(偏移量和文件位置的映射)的大小,我们会预先分配这个索引文件并且只在日志滚动之后压缩它。您通常不需要更改此设置。 |
segment.ms | 7 days | log.roll.hours | 这个配置控制了Kafka强迫日志滚动的时间(生成新的日志段的时间),即使日志段文件没有满。以保证日志保留策略能够删除或压缩旧数据。 |
segment.jitter.ms | 0 | log.roll.jitter.{ms,hours} | 从logRollTimeMillis中减去的最大抖动(时间误差) |