############################# Server Basics #############################
#每一个Broker在集群中的唯一标识。
# 即使Broker的Ip地址发生了变化，broker id只要没变，
#都不会影响consumers的消息情况
broker.id=0
#是否允许Topic被删除，如果是false，使用管理员工具删除Topic的时候，Kafka并不会处理此操作
#delete.topic.enable=true
#Kafka服务器是否可以根据请求自动创建Topic，默认为true。
#如果打开此选项，下面三种请求会触发Topic的自动创建
#1：Producter向某个不存在的Topic写入消息
#2：Consumer从某个不存在的Topic读取消息
#3：Consumer从某个不存在的Topic读取消息
#建议将此选项设置为false，并在使用Topic之前手动创建
#auto.create.topics.enable=true
############################# 下面是服务端网络相关的配置 #############################
#kafka Server使用的协议/主机名以及端口的格式如下：
#liteners=security_protocol://host_name:port
#参考示例：
# listeners=PLAINTEXT://your.host.name:9092
#下面是默认配置，使用PLAINTEXT，端口号是9092
#listeners=PLAINTEXT://:9092
#接受请求的线程数
num.network.threads=3
#执行请求的线程数
num.io.threads=8
#在介绍下面两个缓冲区设置之前，先来介绍一下相关背景知识：
#每个TCP socket在内核中都有一二个发送缓冲区（SO_SNDBUF）
# 和一个接收缓冲区（SO_RCVBUF）.接收缓冲区把数据缓存入内核
#应用进程一直没有调用read进行读取的话，此数据会一直缓存在相应socket的接收缓冲区。
#再罗嗦一点，不管进程是否读取socket，对端发来的数据都会经由内核接收并且缓存到socket
#的内核接受缓冲区中。read所做的工作，就是把内核缓冲区中的数据复制到应用层用户的buffe
#里面，仅此而已。进程调用send发送的数据的时候，一般情况下，将数据复制进入socket的内核发送缓冲区之中
#然后send便会在上层返回。换句话说，send返回之时，数据不一定会发送到对端去，
#send仅仅是把应用层buffer的数据复制进socket的内核发送buffer中
#TCP连接的SO_SNDBUG缓冲区大小，默认为102400,单位是字节
#如果是-1,就使用系统的默认操作值
socket.send.buffer.bytes=102400
#TCP连接的SO_RCVBUF缓冲区大小，默认102400,单位是字节
#如果是-1,就使用系统的默认操作值
socket.receive.buffer.bytes=102400
#请求的最大长度
socket.request.max.bytes=104857600
############################# 下面是存储log相关的配置 #############################
#用于存储log文件的目录，可以将多个目录通过列表分割，形成一个目录列表
log.dirs=/tmp/kafka-logs
# 每个Topic默认的partition数量，默认值是1
num.partitions=1
#用来恢复log文件以及关闭时将log数据刷新到磁盘的线程数量，
#每个目录对应num.recovery.threads.per.data.dir个线程
num.recovery.threads.per.data.dir=1
############################# Internal Topic Settings #############################
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state"
# For anything other than development testing, a value greater than 1 is recommended for to ensure availability such as 3.
offsets.topic.replication.factor=1
transaction.state.log.replication.factor=1
transaction.state.log.min.isr=1
############################# 下面是log文件刷盘的相关配置 #############################
#每隔多少个消息触发一次flush操作，将内存中的消息刷新到磁盘上
#log.flush.interval.messages=10000
#每隔多少毫秒触发一次flush操作，将内存中的消息刷新到磁盘上
# log.flush.interval.ms=1000
#上面这两个配置是全局的，可以在Topic中重新设置，并覆盖这两个配置
############################# 下面是log相关的“保存策略”的配置 #############################
# 注意：下面有两种配置，一种是基于时间的策略，另一种是基于日志文件大小的策略，
#两种策略同时配置的话，只要满足其中一种策略，则出发Log删除的操作。
#删除操作总是先删除最旧的日志
# 消息在Kafka中保存的时间，168小时之前的log可以被删除掉
log.retention.hours=168
#当剩余空间低于log.retention.bytes字节，则开始删除log
#log.retention.bytes=1073741824
#gment日志文件大小的上限值。当超过这个值时，会创建新的segment日志文件
#segment文件的相关信息在后面介绍
log.segment.bytes=1073741824
# 每隔300000ms，logcleaner线程将检查一次，看是否符合上述保留策略的消息可以被删除
log.retention.check.interval.ms=300000
############################# Zookeeper的相关配置 #############################
#Kafka依赖的Zookeeper集群地址，可以配置多个Zookeeper地址，使用逗号隔开
zookeeper.connect=localhost:2181
#ZooKeeper连接的超时时间
zookeeper.connection.timeout.ms=6000
############################# Group Coordinator Settings #############################
# The following configuration specifies the time, in milliseconds, that the GroupCoordinator will delay the initial consumer rebalance.
# The rebalance will be further delayed by the value of group.initial.rebalance.delay.ms as new members join the group, up to a maximum of max.poll.interval.ms.
# The default value for this is 3 seconds.
# We override this to 0 here as it makes for a better out-of-the-box experience for development and testing.
# However, in production environments the default value of 3 seconds is more suitable as this will help to avoid unnecessary, and potentially expensive, rebalances during application startup.
group.initial.rebalance.delay.ms=0