kafka1.1.0
server.properties

broker.id  集群唯一，数字类型，不能为负数。
min.insync.replicas  ISR个数，数据可靠性，配合Producer端 acks 参数
如果可靠性要求较高，建议设置为>=2的值，大于broker节点个数的一半
日志刷盘策略 数据保存在segement文件中（包括用于提高查询效率的index文件）
两种同步刷盘策略 基于时间间隔 基于累计消息条数
基于时间间隔：每隔X毫秒，执行一次文件的fsync操作
基于累计消息条数：每X条消息后，同步执行一次fsync操作。

num.partitions 每个Topic的partition个数，默认1 
日志保留策略 
设定kafka保存消息（数据文件）的时长，也限定consumer允许数据回溯的最大时间。
查出时间阈值的日志文件，可以“压缩备份”，也可以删除。

分组协调


## 开启JMX监控，默认端口5760  
export JMX_PORT=${JMX_PORT:-5760}  
## 基于jolokia + HTTP方式输出监控数据 
## export KAFKA_OPTS="$KAFKA_OPTS -javaagent:/opt/jolokia/jolokia-jvm-1.5-agent.jar"  

Jolokia is remote JMX with JSON over HTTP


kafka broker与client兼容关系描述
https://cwiki.apache.org/confluence/display/KAFKA/Compatibility+Matrix

0.9以上版本的client和broker，低版本client可以访问高版本的broker，
但是高版本的client访问低版本的broker时可能存在兼容性问题。
    
kafka consumer group的几种状态

1）Empty 此group中没有任何消费者在线（曾经提交过offset），可能是新建的group。当一个 Empty的group过期之后，其状态会迁移为 Dead 。
2）PrepareingRebalance 准备进行rebalance，通常是此group中有消费者加入或者离开时（探测周期）触发，这意味着topic/partition在组内多个消费者之间重新分配。
3）AwaitingSync 等待Group Leader重新分配topic/partitions
4）Stable 正常状态
5）Dead：Group内已经没有任何消费者（members），且其offset记录等meta信息即将被删除。
    
    

# 集群唯一 整数 非负数 
broker.id=0  
auto.create.topics.enable=true  
#允许客户端直接删除 
delete.topic.enable=true  
auto.leader.rebalance.enable=true  
# 单条消息最大尺寸，10M  
message.max.bytes=10000120  
replica.fetch.max.bytes=10485760  
# ISR，当Producer Ack模式为“all”时必须等待ISR列表中replicas全部写入成功  
# 如果replicas为3，可设置为2 + ACK=all 确保消息可靠性。  
min.insync.replicas=2  
  
# 默认replication个数，broker=3，replication=2  
default.replication.factor=2  
############################# Socket Server Settings #############################  
listeners=PLAINTEXT://192.168.0.10:9092  
  
# 接收客户端请求的IO线程数 
num.network.threads=3  
  
# 处理请求包括磁盘IO的线程数
num.io.threads=8  
  
# SO_SNDBUF  
socket.send.buffer.bytes=102400  
# SO_RCVBUF  
socket.receive.buffer.bytes=102400  
  
# 单次请求，Server允许接收的最大数据量，避免OOM。默认值为100M（104857600）  
socket.request.max.bytes=104857600  
  
# 等待处理的请求个数，超过阈值将会阻塞网络IO线程（类似backlog）  
queued.max.requests=500  
  
# 客户端等待broker响应最大等待时间（包括重试），Client可配置。默认30000秒。  
request.timeout.ms=15000  
  
# 单个IP允许建立的连接数 默认无限制
max.connections.per.ip=256  
  
############################# Log Basics #############################  
# 底层日志文件保存目录，多个磁盘路径则以逗号分割 
log.dirs=/data/kafka  
   
num.partitions=1  
  
num.recovery.threads.per.data.dir=1  
  
############################# Internal Topic Settings  #############################  
# The replication factor for the group metadata internal topics "__consumer_offsets" and "__transaction_state"  
# kafka内部状态数据将保存在特定的topic中，  
# offsets 保存在 __consumer_offsets   
# 每个producer的事务，保存在 __transaction_state 
# 对于内部topic，其replicas个数，建议为“大多数派”，且最多不要超过3。  
# broker<3,replicas=1;  
# brokers = 3，replicas=2；  
# broker>=5，replicas=3;  
# 线上配置，broker=3；事务功能暂时关闭  
offsets.topic.replication.factor=2  
transaction.state.log.replication.factor=1  
transaction.state.log.min.isr=1  
  
############################# Log Flush Policy #############################  
  
# 日志刷盘策略， 吞吐量优先 vs 数据可靠性优先  
# 吞吐量优先 replicaiton=1  
  
#  两个参数满足其一，即可Flush  
# 吞吐量优先，默认为关闭（Long最大值）  
log.flush.interval.messages=10000  
  
# 可靠性 + 延迟优先，每隔1秒刷盘，通用高优策略。  
log.flush.interval.ms=1000  
  
############################# Log Retention Policy #############################  
  
# 日志保留策略， 保留时间长 存量数据大小 ，超出阈值的日志将会被清理  
log.cleanup.policy=delete  
log.cleaner.enable=true  
# 保留多久则会被cleanup，默认值12小时 
log.cleaner.delete.retention.ms=43200000  
  
# 日志保留 7 天  
log.retention.hours=168  
## 350G  
log.retention.bytes=375809638400  
  
# 底层为LSM树，每个逻辑topic、partition都会有多个segments文件构成，每个segments大小，默认为1G。  
# 建议保持默认  
log.segment.bytes=1073741824  
  
# 检测周期，5分钟  
log.retention.check.interval.ms=300000  
  
############################# Zookeeper #############################  
# 可以包含chroot， host:ip/kafka  
zookeeper.connect=192.168.0.10:2181,192.168.0.11:2181,192.168.0.12:2181/kafka  
zookeeper.connection.timeout.ms=6000  
  
  
############################# Group Coordinator Settings #############################  
# 分组协调 （broker端）  
# rebalance 通常适用 单组 + 多个消费者 场景，此值适用于 消费者入组后，首次relance之前等待的时长  
# 消费者启动可能逐个进行，等待足够多的consumers入组后进行rebalance 
group.initial.rebalance.delay.ms=3000  
group.max.session.timeout.ms=300000  
group.min.session.timeout.ms=6000