num.partitions=1

#全局分区设置 默认1

---

offsets.topic.num.partitions=50

#__consumer_offsets分区设置 默认50

---

default.replication.factor=1

#全局副本设置 默认1

---

offsets.topic.replication.factor=3

#__consumer_offsets副本设置 默认3

---

broker.id.generation.enable 和 reserved.broker.max.id

来配合生成新的 broker.id。
#broker.id.generation.enable参数是用来配置是否开启自动生成 broker.id 的功能，默认情况下为true，即开启此功能。自动生成的broker.id有一个默认值，默认值为1000，也就是说默认情况下自动生成的 broker.id 从1001开始。

---

port

#broker server服务端口

---

logs.dir

#kafka数据的存放地址，多个地址的话用逗号分割,多个目录分布在不同磁盘上可以提高读写性能 /data/kafka-logs-1，/data/kafka-logs-2

---

log.retention.{hous|minutes|ms}

#日志留存时间，默认只保留最近7天的数据。

---

log.retention.bytes

#空间维度上的留存策略，控制着Kafka集群需要为每个消息日志保存多大的数据。对于大小超过该参数的分区日志而言，Kafka会自动清理该分区的过期日志段文件。默认为-1，表示不依据日志大小来清除日志。

---

zookeeper.connect

#无默认值，可以为一个CSV(comma-separated values)逗号分隔值列表，如设置为zk1:2181,zk2:2181,zk3:2181

---

listeners

#broker监听器的CSV列表，格式是[协议]：//[主机名]:[端口], [[协议]：//[主机名]:[端口]]。该参数主要用于客户端连接broker使用，可以认为是broker端开放给clients的监听端口。如果不指定主机名，则表示绑定默认网卡；如果主机名是0.0.0.0，则表示绑定所有网卡。

---

副本同步leader能力参数

1、replica.lag.time.max.ms

#replicas响应leader的最长等待时间，若是超过这个时间，就将replicas排除在ISR之外

---

2、replica.lag.max.messages

#如果relicas落后太多,将会认为此partition relicas已经失效。而一般情况下,因为网络延迟等原因,总会导致replicas中消息同步滞后。如果消息严重滞后,leader将认为此relicas网络延迟较大或者消息吞吐能力有限。在broker数量较少,或者网络不足的环境中,建议提高此值.
Kafka 0.9.0.0版本后移除了replica.lag.max.messages参数，只保留了replica.lag.time.max.ms作为ISR中副本管理的参数

---

3、num.replica.fetchers

(默认:1) - follower从leader拉取消息进行同步数据，是由fetcher线程完成的，fetcher线程数由此参数以及要连接的broker共同决定的控制,

---

4、replica.fetch.max.bytes

(默认: 1MB) – broker可复制的消息的最大字节数。这个值应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去，从而造成数据丢失。

---

message.max.bytes

(默认:1000000)– broker能接收消息的最大字节数，这个值应该比消费端的fetch.message.max.bytes更小才对，否则broker就会因为消费端无法使用这个消息而挂起。

修改 Topic 级 max.message.bytes，要考虑以下两个
还要修改 Broker的 replica.fetch.max.bytes 保证复制正常
消费还要修改配置 fetch.message.max.bytes

---

fetch.message.max.bytes (默认 1MB)

#消费者能读取的最大消息。这个值应该大于或等于message.max.bytes。
所以，如果你一定要选择kafka来传送大的消息，还有些事项需要考虑。要传送大的消息，不是当出现问题之后再来考虑如何解决，而是在一开始设计的时候，就要考虑到大消息对集群和主题的影响。

---

auto.leader.rebalance.enable=false

#是否自动平衡broker之间的分配策略

• 如果为false时，某个broker挂了，那分布在他上的leader副本就会自动切换到其他活着的broker上，但是挂掉的broker重启之后，集群并不会将他之前的leader副本再切换回来，这样就会使其他broker上leader副本数较多，而该broker上无leader副本（无新主题创建），从而造成负载不均衡的情况。
  这时我们可以通过 kafka-preferred-replica-election.sh 脚本来重新平衡集群中的leader副本。

• 如果为true的话，controller角色就会每五分钟（leader.imbalance.check.interval.seconds默认）检查一下集群不平衡的状态（比较leader.imbalance.per.broker.percentage），进而重新平衡leader副本

---

leader.imbalance.per.broker.percentage = 10

#leader的不平衡比例，若是超过这个数值，会对分区进行重新的平衡
比例计算公式为：
（leader不是AR副本集的preferred replica的数量)/(broker 的AR副本数量)

---

leader.imbalance.check.interval.seconds = 300

#检查leader是否不平衡的时间间隔

---

unclean.leader.election.enable

#版本不一样默认值也不一样，建议设置为false

unclean .leader .election .enable 是关闭 Unclean Leader 选举的。何谓 Unclean?还记得Kafka有多个副本这件事吗？每个分区都有多个副本来提供高可用。在这些副 本中只能有一个副本对外提供服务，即所谓的Leader副本。
那么问题了，这些副本都有资格竞争Leader吗？显然不是，只有保存数据比较多的那些副本 才有资格竞选，那些落后进度太多的副本没资格做这件事情
好了，现在出现这种情况了：假设那些保存数据比较多的副本都挂了怎么办？我们还要不要进行 Leader选举了？此时这个参数就派上用场了。
如果设置成false,那么就坚持之前的原则，坚决不能让那些落后太多的副本竞选Leader。这样 做的后果是这个分区就不可用了，因为没有Leader 了。
反之如果是true,那么Kafka允许你从 那些"跑的慢"的副本中选一个出来当Leader。这样做的后果是数据有可能就丢失了，因为这 些副本保存的数据本来就不全，当了 Leader之后它本人就变得膨胀了，认为自己的数据才是权 威的。
这个参数在最新版的Kafka中默认就是false,本来不需要我特意提的，但是比较搞笑的是社区 对这个参数的默认值来来回回改了好几版了，鉴于我不知道你用的是哪个版本的Kafka,所以建 议你还是显式地把它设置成false吧。
注：虽然设置为false会可能导致该partition不可用，但是设置为ture会有丢数据的风险。

---

log.roll.{hours,ms}

日志滚动的周期时间，到达指定周期时间时，强制生成一个新的segment
默认值168(7 day)

---

log.segment.bytes

每个segment的最大容量。到达指定容量时，将强制生成一个新的segment
默认值1G(-1 为不限制)

---

**log.retention.check.interval.ms **

日志片段文件检查的周期时间	
默认值60000

---

Kafka的日志实际上是开始是在缓存中的（linux页缓存），然后根据一定策略定期一批一批写入到日志文件中去，以提高吞吐量.

log.flush.interval.messages

消息达到多少条时将数据写入到日志文件
默认值10000

---

log.flush.interval.ms

当达到该时间时，强制执行一次flush	
默认值null

---

log.flush.shceduler.interval.ms

周期性检查，是否需要将信息flush	

---