以下都是最好显示设置的参数：

1.log.dirs = /home/kafka1,/home/kafka2,/home/kafka3　　指定了 Broker 需要使用的若干个文件目录路径。（还有一个log.dir参数用于补充log.dirs的单个路径配置，但基本不用，配置log.dirs即可）

多路径时，最好保证这些目录挂载到不同的物理磁盘上，好处：

  • 提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。
  • 能够实现故障转移：即 Failover。（Kafka 1.1 版本新引入的强大功能，以前，只要 Kafka Broker 使用的任何一块磁盘挂掉了，整个 Broker 进程都会关闭。但是自 1.1 开始，这种情况被修正了，坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上，而且 Broker 还能正常工作。这个改进正是舍弃 RAID 方案的基础：没有这种 Failover 的话，我们只能依靠 RAID 来提供保障。）

Zookeeper相关参数：

2.zookeeper.connect = zk1:2181,zk2:2181,zk3:2181/kafka1　　需在/etc/hosts 里面配置zk1,zk2,zk3，/kafka1是chroot，指定zk创建在这路径下，否则就在zk根目录创建（多个kafka注册到同一个zk集群时，最好带上chroot用以区分）

 

下面两个与brokers相关的参数

3.listeners　　告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务

4.advertised.listeners　　配置的这组监听器是 Broker 用于对外发布的

监听器是三元组，<协议名称，主机名，端口号>，协议名称可能是标准的名字，比如 PLAINTEXT 表示明文传输、SSL 表示使用 SSL 或 TLS 加密传输等；也可能是你自己定义的协议名字，比如CONTROLLER: //localhost:9092。

定义了协议名称，你必须还要指定listener.security.protocol.map参数告诉这个协议底层使用了哪种安全协议，比如指定listener.security.protocol.map=CONTROLLER:PLAINTEXT表示CONTROLLER这个自定义协议底层使用明文不加密传输数据。

三元组中最好全部使用主机名，即 Broker 端和 Client 端应用配置中全部填写主机名。 Broker 源代码中也使用的是主机名，如果你在某些地方使用了 IP 地址进行连接，可能会发生无法连接的问题。

 

Topic管理的参数：

5.auto.create.topics.enable = false　　是否允许自动创建 Topic，建议是false，避免出现写错了topic名字自动创建了奇怪的topic。

6.unclean.leader.election.enable = false　　是否允许 Unclean Leader 选举，默认false，多副本中只有一个leader副本提供服务，有一种情况：假设那些保存数据比较多的副本都挂了怎么办？我们还要不要进行 Leader 选举了？设置成 false，那么就坚持之前的原则，坚决不能让那些落后太多的副本竞选 Leader。这样做的后果是这个分区就不可用了，因为没有 Leader 了。反之如果是 true，那么 Kafka 允许你从那些“跑得慢”的副本中选一个出来当 Leader。这样做的后果是数据有可能就丢失了。

7.auto.leader.rebalance.enable = false　　是否允许定期进行 Leader 选举，建议false，因为更换leader的成本是很高的，原本向 A 发送请求的所有客户端都要切换成向 B 发送请求，而且这种换 Leader 本质上没有任何性能收益。

 

数据相关（Brokers级别）

8.log.retention.{hour|minutes|ms}　　控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hour 最低。一般设置log.retention.hour=168表示默认保存 7 天的数据，自动删除 7 天前的数据。如果想把kafka当存储用，那就要设置大。

9.log.retention.bytes　　指定 Broker 为消息保存的总磁盘容量大小，默认-1，即保存多少数据都可以，真正发挥作用是在云上构建多租户的 Kafka 集群的场景，每个租户只能使用 100GB 的磁盘空间，为了避免有个“恶意”租户使用过多的磁盘空间。

10.message.max.bytes　　控制 Broker 能够接收的最大消息大小，默认的 1000012 太少了，还不到 1MB，建议设置大一些。

 

Topic级别参数（brokers是全局的参数），可在在创建topic的时候kafka-topics命令用--config后带上该参数设置，也可以用kafka-configs脚本来调整：

11.retention.ms　　规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。

12.retention.bytes　　规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的 Kafka 集群中会有用武之地。当前默认值是 -1，表示可以无限使用磁盘空间。

13.max.message.bytes　　它决定了 Kafka Broker 能够正常接收该 Topic 的最大消息大小。

 

14.运行kafka 的JVM参数设置：

比较通用的设置：将 JVM 堆大小设置成 6GB ，业界相对公认的合理数值。

垃圾收集使用：

  • 如果 Broker 所在机器的 CPU 资源非常充裕，建议使用 CMS 收集器。启用方法是指定-XX:+UseCurrentMarkSweepGC。
  • 否则，使用吞吐量收集器。开启方法是指定-XX:+UseParallelGC

如果是java 8以上直接用G1.

如何设置？启动broker前：

export KAFKA_HEAP_OPTS=--Xms6g  --Xmx6g
export  KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true
bin/kafka-server-start.sh config/server.properties

 

15.运行kafka的操作系统参数设置

主要有这几个方面：

  • 文件描述符限制
  • 文件系统类型
  • Swappiness
  • 提交时间

文件描述符真的不昂贵，可以设置ulimit -n 1000000

文件系统XFS 的性能要强于 ext4，ZFS 显示更好，但没有实际测试过

swap 的调优，设置0可以禁掉以防止 Kafka 进程使用 swap 空间，一旦设置成 0，当物理内存耗尽时，操作系统会触发 OOM killer 这个组件，它会随机挑选一个进程然后 kill 掉，即根本不给用户任何的预警。

所以设置一个较小值，如1，当开始使用 swap 空间时，至少能够观测到 Broker 性能开始出现急剧下降，从而给你进一步调优和诊断问题的时间。

提交时间，也是Flush 落盘时间，向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功，而是只要数据被写入到操作系统的页缓存（Page Cache）上就可以了，随后操作系统根据 LRU 算法会定期将页缓存上的“脏”数据落盘到物理磁盘上。

这个定期就是由提交时间来确定的，默认是 5 秒，可以适当调整大，来降低物理磁盘的写操作， Kafka 在软件层面已经提供了多副本的冗余机制，稍微拉大提交间隔去换取性能还是一个合理的做法。