kafka配置详解

broker端参数

• log.dirs：指定broker端使用那些若干文件来进行日志存储，没有默认值，必须要进行指定。配置格式为csv的样式，如：/home/kafka1,/home/kafka2,/home/kafka3，并且可以将不同的目录挂在不同的磁盘下面，这样可以有如下好处

提升读写性能
可以实现故障转移，在kafka1.1之后，单个磁盘损坏时，坏掉的磁盘数据会自动转换到正常的磁盘，继续提供服务。

• log.dir：同log.dirs参数配置效果一样，只不过只能配置单个路径。
• zookeeper.connect：参数格式也是CSV，例如zk1:2181，zk2:2182，zk3:2181,如果多个kafka集群公用一个zookeeper，那么可以使用chroot来方便配置项，chroot类似于别名的作用，例如有两个kafka集群，分别为kafka1、kafka2，那么可以写成如下配置

zk1:2181,zk2:2181,zk3:2181/kakfa1和zk1:2181,zk2:2181,zk3:2181/kafka2,chroot只需要配置一次

• listeners：又称为监听器，作用就是告诉客户端使用什么样的协议、主机名和端口号来访问服务器。
• advertised.listeners：说明这组监听器是broker用于对外发布的。

监听器的配置，主要是有若干个逗号分隔的三元组构成，三元组的结构<协议名称，主机名，端口号>。常用的协议有PLAINTEXT：表示明文传输；SSL表示使用SSL或TLS加密传输。
也可以自定义协议，例如HDD：//localhost:9200，如果使用了自定义的协议，还需要配置另一个参数listener.security.protocol.map，表明这个协议的底层采用什么进行传输
如：listener.security.protocol,map=HDD:PLAINTEXT,表明HDD协议底层采用明文传输。

• auto.create.topics.enable：是否允许自动创建topic，这个参数一般设置为false，即不允许自动创建topic，可以防止topic命名不规范，而产生很多topic，并且topic的使用，需要专门进行申请。
• unclean.leader.election.enable：是否允许非ISR集合中的分区进行leader选举，参数建议设置为false，即不允许落后于leader副本太多的follower分区进行leader选举，可以保证因为leader选举导致的消息丢失。
• auto.leader.rebalance.enable：是否允许定期进行leader选举，这个参数的作用是用来放leader部分不均衡时，会进行leader选举，重换leader，一般建议设置为false。
• log.retention.{hours | minutes | ms}：这三个参数，是用来控制消息保留的时间的，优先级来说 ms > minutes > hours ，但一般只需配置hours即可，默认配合为168h，即7天。
• log.retention.bytes：表示broker端，为保存消息的总磁盘容量大小，一般设置为-1，即不设限制
• message.max.bytes：表示broker端，能接受的最大消息，默认值为1000012B，在生产上，建议将此参数适当调大。

Producer端参数

• acks：用来指定分区中需要多少个副本收到这条消息后，生产者才认为这条消息发送成功。

acks = 1，为默认参数，表示只要leader副本写入成功，就认为消息发送成功。
acks = 0，表示发送消息后，不需要等待客户端响应。
acks = -1，ISR中的全部副本写入成功，才算这条消息发送成功。

• max.request.size:表示生产者能发送的消息的最大值，默认为1048576B，即1MB。此参数最好不要随意修改，因为还涉及一些和其他参数的联动，比如和broker端message.max.bytes参数，配合使用来限制消息的大小。
• retries和retry.backoff.ms：其中retries表示生产者消息发送失败时的重试次数，默认值为0，因为有些异常可以通过重试解决（如：网络抖动、leader副本选举），那么可以通过retries来实现消息的重试；retry.backoff.ms默认值为100，表示两次重试之间的时间间隔，设置合理值，可以避免无效的频繁重试。（如业务发送了限流，频繁的重试只会加剧限流效应）
• compression.type：用来表示消息的压缩方式，默认值为“none”，可以配置为kafka2.1.0版本之前，支持三种压缩算法：GZIP、Snappy、LZ4。从2.1.0开始，kafka正式支持Zstandard 算法，对消息进行压缩可以减少网络传输，降低网络I/O
• receive.buffer.bytes：设置Socket接收消息缓冲区（SO_RECBUF）的大小，默认值为32768B，即32kb，如何设置为-1，则使用操作系统的默认值。
• send.buffer.bytes:设置Socket发送消息缓冲区（SO_SNDBUF）的大小，默认值为131072B，即128KB。如果设置为-1，表示使用操作系统的默认值。
• request.buffer.bytes:设置Producer等待请求响应的最长时间，默认值为30000ms

更多参数配置可以参考实体ProducerConfig

Consumer端参数

• fetch.min | max.bytes：设置Consumer一次拉取请求中最小（最大）的数据量，最小默认值1B（最大默认值52428800B，即50MB），当kafka收到consumer的拉取请求时，如果数量小于这个值，那么consumer端就需要进行等待，直到数据量满足这个值才会返回。
• fetch.max.wait.ms:表示consumer等待多长时间后，返回响应，默认值为500ms，如果一次来取中，消息大小一直小于fetch.min.bytes的值，那么到达fetch.max.wait.ms设置的值后，也会返回响应。
• max.partition.fetch.bytes：表示每个分区中返回给Consumer的最大数据量，默认值为1048576B，即1MB。
• max.poll.records：用来设置Consumer端一次拉取请求中拉取的最大消息数，默认值为500条。
• connections.max.idle.ms：表示多久之后关闭空闲连接，默认值540000ms，即9分钟。
• receive.buffer.bytes：设置Socket接收消息缓冲区（SO_RECBUF）的大小，默认值为65536B，即64kb，如何设置为-1，则使用操作系统的默认值。
• send.buffer.bytes:设置Socket发送消息缓冲区（SO_SNDBUF）的大小，默认值为131072B，即128KB。如果设置为-1，表示使用操作系统的默认值。
• request.timeout.ms：Consumer等待请求响应的最长时间，默认值为30000ms。
• metadata.max.age.ms：设置配置的元数据的过期时间，默认值为300000ms，即5分钟，表示，在5分钟内，元数据没有被更新时，会被强制进行更新。

更多参数配置可以参考实体ConsumerConfig

Topic参数

• retention.ms:该参数指定topic的消息保存时间，默认为7天，topic设置了这个参数后，就会覆盖broker端的全局配置。
• retention.bytes：该参数指定为topic预留多大的磁盘空间。默认值为-1，表示不限制。
• max.message.bytes:可设置单个topic的最大消息体。

topic设置的两个方式

• 创建topic时进行设置

bin/kafka-topic.sh --bootstrap-server localhost:9200 --create --topic test --partitions 1 --replication-factor 1 --config retention.ms=15552000000 --config max.message.bytes=5242880

• 修改topic时设置,最好使用这个方式

bin/kakfka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name test --alter --add-config max.message.bytes=10485760

操作系统参数

• 文件描述符限制：ulimit -n 1000000，如果这个参数设置的过小就会报“Too many open files”的错误。
• 文件系统类型：可选项有ext3，ext4和XFS、ZFS。其性能其 ZFS > XFS > ext4。
• Swappiness：如果将swap设置为0，一旦机器的内存耗尽，操作系统会触发OOM killer这个组件，它会随机挑选一个进程然后 kill 掉。所以可以给swap设置一个较小的值，比如为1。
• 提交时间：即Flush刷盘时间，消息都是先写入操作系统的页缓存（Page Cache），然后操作系统会根据LRU算法定期的将页缓存的“脏”数据刷到磁盘，这个时间默认时5s。一般可适当调大这个值，来减少频繁的刷盘操作，但是风险就是增加了数据丢失的机率，但是kafka通过副本机制，可以适当规避这个风险。