概要描述

本文旨在介绍kafka常用参数

详细说明

1.介绍kafka配置文件参数

listeners=SASL_PLAINTEXT://ts-mjx-22:9092
监听端口配置（hostname每个节点配置的都不同）
advertised.listeners=SASL_PLAINTEXT://ts-mjx-22:9092
监听端口配置（hostname每个节点配置的都不同）

num.network.threads=2 接收网络请求的线程数

num.io.threads=2 处理磁盘IO的线程数

socket.send.buffer.bytes=1048576
发送缓冲区大小

socket.receive.buffer.bytes=1048576
接收缓冲区的大小

socket.request.max.bytes=104857600
每个请求最大的字节数 为了防止内存溢出，message.max.bytes必然要小于该值

log.dirs=/vdir/mnt/disk1/hadoop/kmq,/vdir/mnt/disk2/hadoop/kmq,/vdir/mnt/disk3/hadoop/kmq 收到的消息存储在这

num.partitions=2
创建topic不指定分区数的时候，默认2个分区

num.recovery.threads.per.data.dir=1
恢复磁盘时，并发的线程数。RAID阵列建议提高并发

log.flush.interval.messages=10000
当达到上面的消息数量时，会将数据flush到日志文件中。默认10000

log.flush.interval.ms=1000
当达到上面的时间(ms)时，执行一次强制的flush操作。interval.ms和interval.messages无论哪个达到，都会flush。默认3000ms

log.flush.scheduler.interval.ms=3000
检查是否需要将日志flush的时间间隔

log.retention.hours=168 日志7天会被删除

log.retention.bytes=-1 达到多少字节会被删除

log.segment.bytes=536870912
控制日志segment文件的大小，超出该大小则追加到一个新的日志segment文件中（-1表示没有限制）

log.retention.check.interval.ms=300000
日志片段文件的检查周期，查看它们是否达到了删除策略的设置（log.retention.hours或log.retention.bytes）

log.roll.hours=168 当达到这个时间，会强制新建一个segment

log.index.size.max.bytes=10485760
对于segment日志的索引文件大小限制

log.index.interval.bytes=4096
索引计算的一个缓冲区，一般不需要设置。

zookeeper方面的配置：
zookeeper.connect=ts-mjx-21,ts-mjx-22,ts-mjx-23

zookeeper.connection.timeout.ms=6000
连接zk的超时时间

zookeeper.session.timeout.ms=6000
ZK客户端与服务器的连接超时时间

zookeeper.sync.time.ms=2000
ZooKeeper
集群中leader和follower之间的同步时间

replica.high.watermark.checkpoint.interval.ms=5000
每个replica将最高水位进行flush的时间间隔

partition.assignment.strategy=roundrobin 分区策略

controlled.shutdown.max.retries=3
控制器关闭的尝试次数

offsets.retention.minutes=10080
offset保留时间

replica.fetch.max.bytes=1000000
replicas每次获取数据的最大字节数

log.segment.bytes.per.topic=100000
单topic日志segment文件的大小

queued.max.requests=500
等待IO线程处理的请求队列最大数

fetch.purgatory.purge.interval.requests=10000
读取请求清除的间隔

replica.socket.receive.buffer.bytes=65536
leader复制的socket缓存大小

replica.fetch.wait.max.ms=500 replicas
同leader之间通信的最大等待时间，失败了会重试

replica.fetch.min.bytes=500
每一个fetch操作的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会等待直到数据达到这个大小

log.roll.hours.per.topic=1
单topic强制新建一个segment的时间

controller.message.queue.size=10 controller-to-broker-channels
消息队列的尺寸大小

replica.socket.timeout.ms=30000
leader与replicas的socket超时时间

num.replica.fetchers=1
leader中进行复制的线程数，增大这个数值会增加relipca的IO

replica.lag.time.max.ms=10000
如果replicas落后太多,将会认为此partition relicas已经失效。而一般情况下,因为网络延迟等原因,总会导致replicas中消息同步滞后。如果消息严重滞后,leader将认为此replicas网络延迟较大或者消息吞吐能力有限。在broker数量较少,或者网络不足的环境中,建议提高此值.

producer.purgatory.purge.interval.requests=10000
生产者请求清理的清理间隔。

message.max.bytes=1000000
消息体的最大大小，单位是字节

controller.socket.timeout.ms=30000
partition management controller 与replicas之间通讯的超时时间

controlled.shutdown.retry.backoff.ms=5000
每次关闭尝试的时间间隔

default.replication.factor=1
一个topic ，默认分区的replication个数 ，不能大于集群中broker的个数

auto.create.topics.enable=true
是否允许自动创建topic ，若是false，就需要通过命令创建topic

controlled.shutdown.enable=false
是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader，并转移到其他broker

auto.commit.enable = true
true时，Consumer会在消费消息后将offset同步到zookeeper，这样当Consumer失败后，新的consumer就能从zookeeper获取最新的offset
消息的确认模式

request.required.acks = 0
0：不保证消息的到达确认，只管发送，低延迟但是会出现消息的丢失，在某个server失败的情况下，有点像TCP
1：发送消息，并会等待leader 收到确认后，一定的可靠性
-1：发送消息，等待leader收到确认，并进行复制操作后，才返回，最高的可靠性

request.timeout.ms = 10000
消息发送的最长等待时间