1、Kafka与不同的操作系统

Kafka在Linux上的表现会优于其他两个，原因如下：

（1）I/O 模型的使用：就是操作系统执行 I/O 指令的方法。

（2）数据网络传输效率

（3）社区支持度

2、broker端参数

首先broker是需要配置存储信息的，即broker使用哪些磁盘。

log.dirs：这是非常重要的参数，指定了 Broker 需要 使用的若干个文件目录路径。要知道这个参数是没有默认 值的，这说明什么？这说明它必须由你亲自指定。

log.dir：注意这是 dir，结尾没有 s，说明它只能表示 单个路径，它是补充上一个参数用的。

只要设置 log.dirs，即第一个参数就好了，不要设置log.dir。而 且更重要的是，在线上生产环境中一定要为log.dirs配置 多个路径，具体格式是一个 CSV 格式，也就是用逗号分隔 的多个路径

3、与zookeeper相关的配置

zookeeper：是一个分布式协调框架，负责协调管理并保 存 Kafka 集群的所有元数据信息，比如集群都有哪些Broker 在运行、创建了哪些 Topic，每个 Topic 都有多少 分区以及这些分区的 Leader 副本都在哪些机器上等信息。

zookeeper.connect。这也是一个 CSV 格式的参数，比 如我可以指定它的值为 zk1:2181,zk2:2181,zk3:2181。2181 是 ZooKeeper 的默认端口。

4、与broker连接相关的参数

listeners：学名叫监听器，其实就是告诉外部连接者 要通过什么协议访问指定主机名和端口开放的 Kafka 服 务。

advertised.listeners：和 listeners 相比多了个 advertised。Advertised 的含义表示宣称的、公布的， 就是说这组监听器是 Broker 用于对外发布的。

host.name/port：列出这两个参数就是想说你把它们 忘掉吧，压根不要为它们指定值，毕竟都是过期的参数了。

监听器的概念：从构成上来说，它是若干个逗 号分隔的三元组，每个三元组的格式为。这里的协议名称可能是标准的名字，比如 PLAINTEXT 表示明文传输、SSL 表示使用 SSL 或 TLS 加密 传输等；也可能是你自己定义的协议名字。

5、关于topic管理的参数

auto.create.topics.enable：是否允许自动创建 Topic。：建议最好设置成 false，即不允许自动创建 Topic。在我们的线上环境里面有 很多名字稀奇古怪的 Topic，我想大概都是因为该参数被设 置成了 true 的缘故。

unclean.leader.election.enable：是否允许 Unclean Leader 选举。：是关闭 Unclean Leader 选举的。何谓 Unclean？还记得 Kafka 有 多个副本这件事吗？每个分区都有多个副本来提供高可用。 在这些副本中只能有一个副本对外提供服务，即所谓的 Leader 副本。建议设置为false。

auto.leader.rebalance.enable：是否允许定期进 行 Leader 选举。：设置它的值 为 true 表示允许 Kafka 定期地对一些 Topic 分区进行 Leader 重选举，当然这个重选举不是无脑进行的，它要满 足一定的条件才会发生。严格来说它与上一个参数中Leader 选举的最大不同在于，它不是选 Leader，而是换 Leader！比如 Leader A 一直表现得很好，但若 auto.leader.rebalance.enable=true，那么有可能 一段时间后 Leader A 就要被强行卸任换成 Leader B。换leader成本很高，建议设置为false。

6、数据留存方面的参数

log.retention.{hour|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先 级上来说 ms 设置最高、minutes 次之、hour 最低。虽然 ms 设置有最高的优先级，但是 通常情况下我们还是设置 hour 级别的多一些，比如 log.retention.hour=168表示默认保存 7 天的数据，自动删除7天前的数据。

log.retention.bytes：这是指定 Broker 为消息保存的总磁盘容量大小。默认值是-1，表示你再这台broker上面想保存多少数据都可以。

message.max.bytes：控制 Broker 能够接收的最大消息大小。

7、topic级别的参数

topic级别参数和全局broker参数，到底听谁的？topic级别的参数会覆盖掉全局broker参数。

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

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

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

8、JVM参数

将 JVM堆大小设置成 6GB， 这是目前业界比较公认的一个合理值。默认值是1GB，有点小了。

Java8的运行环境下GC回收器用G1就行。

KAFKA_HEAP_OPTS：指定堆大小。

KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。

9、操作系统参数

ulimit -n。任何一个 Java 项目最好都调整 下这个值。实际上，文件描述符系统资源并不像我们想象的 那样昂贵，你不用太担心调大此值会有什么不利的影响。通 常情况下将它设置成一个超大的值是合理的做法。

文件类型的选择：XFS的性能强于ext4，生产环境推荐使用XFS

swap调优：网上很多文章都提到设置其为 0，将 swap 完全禁掉以防止 Kafka 进程使用 swap 空间。反倒觉得还是不要设置成 0 比较好，我们可以设置成一个较 小的值。为什么呢？因为一旦设置成 0，当物理内存耗尽 时，操作系统会触发 OOM killer 这个组件，它会随机挑选 一个进程然后 kill 掉，即根本不给用户任何的预警。但如果 设置成一个比较小的值，当开始使用 swap 空间时，你至少 能够观测到 Broker 性能开始出现急剧下降，从而给你进一 步调优和诊断问题的时间。基于这个考虑，建议将 swappniess 配置成一个接近 0 但不为 0 的值，比如 1。

提交时间或者说是 Flush 落盘时间：向 Kafka 发送 数据并不是真要等数据被写入磁盘才会认为成功，而是只要 数据被写入到操作系统的页缓存（Page Cache）上就可以 了，随后操作系统根据 LRU 算法会定期将页缓存上 的“脏”数据落盘到物理磁盘上。这个定期就是由提交时间 来确定的，默认是 5 秒。一般情况下我们会认为这个时间太频繁了，可以适当地增加提交间隔来降低物理磁盘的写操作。