前文链接：
（一）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中减去的最大抖动（时间误差） |