常规配置
1）broker.id
broker.id=1broker的标识符。默认值是0，可以任意选定 其他任意整数，但在整个Kafka 集群里必须是唯一的。
建议把它们设置成与机器名具有相关性的整数，这样在进行维护时，将ID 号映射到机器名就没那么麻烦了。例如，如果机器名包含唯一性的数字（比如hostl . example.com 、host2.example.com ），那么用这些数字来设置broker.id 就再好不过了。
2）port
port=9092
如果使用配置样本来启动Kafka ，它会监听9092 端口。修改port 配置参数可以把它设置成其他任意可用的端口。
3）zookeeper.connect
zookeeper.connect=localhost:2181用于保存broker元数据的zookeeper地址是通过zookeeper.connect来指定的。
localhost:2181 表示这个zookeeper是运行在本地的2181端口上。
该配置参数是用冒号分隔的一组hostname:port/path 列表：
hostname zookeeper 服务器的机器名或IP 地址：
port 是Zookeeper 的客户端连接端口z
/path 是可选的Zookeeper 路径,作为Kafka 集群的chroot 环境。
如果不指定，默认使用根路径。
如果指定的chroot 路径不存在,broker会在启动的时候创建它。
zookeeper群组可以共享给其他应用程序，即使还有其他Kafka集群存在， 也不会产生冲突。
在配置文件里指定一组zookeeper服务器，用分号把它们隔开。一旦有一个zookeeper服务器岩机，broker可以连接到zookeeper群组的另一个节点上。
4）log.dirs
log.dirs=/tmp/kafka-logsKafka把所有消息都保存在磁盘上，存放这些日志片段的目录是通过log.dirs 指定的。
它是一组用逗号分隔的本地文件系统路径。如果指定了多个路径，那么broker会根据“最少使用”原则，把同一个分区的日志片段保存到同一个路径下。要注意，broker会往拥有最少数目分区的路径新增分区，而不是往拥有最小磁盘空间的路径新增分区。
5）num.recovery.threads.per.data.dir
num.recovery.threads.per.data.dir=1对于如下情况,Kafka会使用可配置的钱程池来处理日志片段：
服务器正常启动 用于打开每个分区的日志片段
服务器崩愤后重启 用于检查和截短每个分区的日志片段
服务器正常关闭 用于关闭日志片段
默认情况下，每个日志目录只使用一个线程。
特别是对于包含大量分区的服务器来说， 一旦发生崩愤，在进行恢复时使用并行操作可能会省下数小时的时间。
也就是说，如果num.recovery.threads.per.data.dir=8， 井且log.dirs指定了3 个路径，那么共需要24 个线程。
6）auto.create.topics.enable
默认情况下,Kafka 会在如下情形下自动创建主题：
当一个生产者开始往主题写入消息时
当一个消费者开始从主题读取消息时
当任意一个客户端向主题发送元数据请求时
很多时候，这些行为都是非预期的。而且,根据Kafka协议，如果一个主题不先被创建，根本无法知道它是否已经存在。
如果显式地创建主题,手动创建或是通过其他配置系统来创建，都可以把auto.create.topics.enable=false
主题的默认配置
1）num.partitions
num.partitions=1指定了新创建的主题将包含几个分区。默认值是1。
Kafka 集群通过分区对主题进行横向扩展，所以当有新的broker 加入集群时，可以通过分区个数来实现集群的负载均衡。
如何选定分区数量:
1)主题需要达到多大的吞吐量？例如，是希望每秒钟写入1OOKB 还是1GB?
2)从单个分区读取数据的最大吞吐量是多少？每个分区一般都会有一个消费者，如果你知道消费者将数据写入数据库的速度不会超过每秒50MB ，那么你也该知道，从一个分区读取数据的吞吐量不需要超过每秒50MB 。
3)可以通过类似的方法估算生产者向单个分区写入数据的吞吐量，不过生产者的速度一般比消费者快得多，所以最好为生产者多估算一些吞吐量。
4)每个broker 包含的分区个数、可用的磁盘空间和网络带宽。
5)如果消息是按照不同的键采写入分区的，那么为已有的主题新增分区就会很困难。
6)单个broker对分区个数是有限制的，因为分区越多，占用的内存越多，完成首领选举需要的时间也越长。
2）log.retention.ms
log.retention.hours=168
根据时间来决定数据被保留多久。默认使用log.retention.hours参数来配置时间，默认值为168 小时，也就是一周。
除此以外，还有其他两个参数log.retention.minutes、log.retention.ms，作用是一样的。
如果指定了不止一个参数, Kafka会优先使用具有最小值的那个参数。
3）log.retention.bytes
log.retention.bytes=1073741824
通过保留的消息字节数来判断消息是否过期，作用在每一个分区上。
如果有一个包含8个分区的主题，井且log.retention.bytes=1GB ，那么这个主题最多可以保留8GB 的数据。
如果同时指定了log.retention.bytes和log.retention.ms，只要任意一个条件得到满足，消息就会被删除。
假设log.retention.ms=86 400 000 （也就是1 天） ,log.retention.bytes=1 000 000 000(也就是1GB)，
如果消息字节总数在不到一天的时间就超过了1GB ，那么多出来的部分就会被删除。
相反，如果消息字节总数小于1GB ，那么一天之后这些消息也会被删除，尽管分区的数据总量小于1GB 。
4）log.segment.bytes
log.segment.bytes=1073741824
以上的设置都作用在日志片段上，而不是作用在单个消息上。
当消息到达broker时，它们被迫加到分区的当前日志片段上。当日志片段大小达到log.retention.bytes指定的上限(默认是1GB)时，当前日志片段就会被关闭，一个新的日志片段被打开。
若一个日志片段被关闭，就开始等待过期。这个参数的值越小，就会越频繁地关闭和分配新文件，从而降低磁盘写入的整体效率。
例如，如果一个主题每天只接收100MB的消息，log.retention.bytes使用默认设置，那么10天时间才能填满一个日志片段。
在日志片段被关闭之前消息是不会过期的，如果log.retention.ms=604 800 000(也就是1周)，那么日志片段最多需要17天才会过期,要等到日志片段里的最后一个消息过期才能被删除.
日志片段的大小会影响使用时间戳获取偏移量。在使用时间戳获取日志偏移量时，Kafka会检查分区里最后修改时间大于指定时间戳的日志片段（已经被关闭的），该日志片段的前一个文件的最后修改时间小子指定时向戳。然后，Kafka返回该日志片段（也就是文件名）开头的偏移量。对于使用时间戳获取偏移量的操作来说，日志片段越小，结果越准确。
5）log.segment.ms
控制日志片段关闭时间,指定了多长时间之后日志片段会被关闭。
log.segment.bytes和log.segment.ms不存在互斥问题。日志片段会在大小或时间达到上限时被关闭，看哪个条件先得到满足。
默认情况下，log.segment.ms没有设定值，所以只根据大小来关闭日志片段。
在使用基于时间的日志片段时，要着重考虑并行关闭多个日志片段对磁盘性能的影响。
如果多个分区的日志片段永远不能达到大小的上限，就会发生这种情况，因为broker 在启动之后就开始计算日志片段的过期时间，对于那些数据量小的分区来说，日志片段的关闭操作总是同时发生。
6 ）message.max.bytes
broker通过设置message.max.bytes参数来限制单个消息的大小，默认值是1 000 000 ，也就是lMB 。
如果生产者尝试发送的消息超过这个大小，不仅消息不会被接收，还会收到broker返回的错误信息。
跟其他与字节相关的配置参数一样，该参数指的是压缩后的消息、大小，也就是说，只要压缩后的消息小于message.max.bytes指定的值，消息的实际大小可以远大于这个值。
这个值对性能有显著的影响。值越大，那么负责处理网络连接和请求的线程就需要花越多的时间来处理这些请求。它还会增加磁盘写入块的大小，从而影响IO吞吐量。
消费者客户端设置的fetch.message.max.bytes 必须与服务器端设置的消息大小进行协调。
如果这个值比message.max.bytes小，那么消费者就无法读取比较大的消息，导致出现消费者被阻塞的情况。
在为集群里的broker 配置replica.fetch.max.bytes 参数时,也遵循同样的原则。