前言

毫无疑问首先需要了解kafka各组件的概念，然后我个人觉得在日常的开发中其实去熟悉kafka的集群配置是非常重要且优先级很高的一环，因为原理性的东西很多，想去学习源码更不是一天两天就能做完的事，但是生产环境的kafka集群配置不当可能会引发未知且棘手的问题，最后一查问题根源就出在开始最简单的配置上。

Broker端配置

  1. log.dirs
    log.dirs这个参数没有默认值，必须要去指定！！！它指定了Broker需要使用的若干个文件路径，它的格式比如：/home/kafka1,/home/kafka2,/home/kafka3
    有条件的情况下尽量保证这些目录挂载在不同的物理磁盘上，这样做有两个好处：
  • 一是多块磁盘同时写数据有更多的吞吐量
  • 二是一块磁盘出现问题，数据会转移到正常的磁盘上，即failover
  1. topic管理
  • auto.create.topics.enable：是否允许自动创建 Topic
    这里最好设置成false，防止线上稀奇古怪的topic名字被创建，因为它是没有就自动创建，比如应用程序里拼错了topic名字，一旦运行就创建了这个拼写错误的topic名字，运维应该对每一个topic名字进行严格把控。
  • unclean.leader.election.enable：是否允许 Unclean Leader 选举，在不同的kafka版本里面这个默认值是不一样的，建议无论哪个版本都要设置成false，不允许数据落后太多的副本竞选leader，否则可能会导致数据丢失，因为落后的副本数据本来就不全。
  • auto.leader.rebalance.enable：是否允许定期进行 Leader 选举。这里要设置成false，因为换一次leader的成本非常高，但却带来不了什么收益，本来A作为leader跑的好好的，但是此时定期把B作为leader选了出来肯定是很不好的event。
  1. 数据留存
    message.max.bytes这个配置默认消息的最大是1000012byte，还不到1MB，实际场景突破1MB的场景并不少见

Topic级别参数

首先明确topic级别参数会覆盖全局Broker级别的参数，比如我们根据业务每个topic并不需要同样的留存时间，所以各自业务的topic可以根据实际需求来设置保存的时长。
还有比如max.message.byte这个参数在全局Broker层面不好把控多大，但是在topic级别根据业务设计这个参数的大小就非常有必要了。

JVM参数

Broker和客户端交互的时候会在JVM上创建大量Byte Buffer参数，所以Heap Size不能太小，而kafka默认的1G确实有点小，这里建议无脑设置成6G，这个是比较通用的最佳实践值，也可以通过监控堆的实时的大小，特别是GC后的live data的大小，通常将heap size设置成其1.5-2倍即可

OS参数

  1. ulimit -n 这个值是用来限制os文件描述符的数量，不用担心将其设置太大有什么不利的影响，这个参数不重要，但是没有的话后果就很严重，比如会经常看到”too many open files“的错误。
  2. 文件系统的选择，推荐使用XFS
  3. flush落盘时间，向kafka发送数据不是等数据写入到磁盘才表示发送成功，而是数据被操作系统写入页缓存即可，虽然操作系统会根据LRU算法将数据落盘，这个定期时间就是由提交时间决定的，默认时间是5s，这个频率我们可以认为比较频繁了，可以适当的提高来提高物理磁盘的写效率，当然这样可能会存在缓存写入磁盘前机器宕机了，那么数据就会丢失了。但是kafka 在软件层面提供了多副本冗余机制，这里就可以适当提升刷盘时间来提升性能是合理的做法。

结束语

希望在使用kafka能注意下这些参数配置，当然不是说其他的参数配置就不重要了，参数配置切记要因环境而异，一定要结合自身业务需要以及具体的测试来验证它们的有效性。