Kafka核心技术与实战——08 | 最最最重要的集群参数配置（下）

猫咪的一生

2020-05-03

关注关注

下半部分主要是 Topic 级别参数、JVM 参数以及操作系统参数的设置
- 正确设置这些参数是搭建高性能 Kafka 集群的关键因素
Topic 级别参数
- 如果同时设置了 Topic 级别参数和全局 Broker 参数
  - 答案就是 Topic 级别参数会覆盖全局 Broker 参数的值，而每个 Topic 都能设置自己的参数值，这就是所谓的 Topic 级别参数
  - 更适当的做法是允许不同部门的 Topic 根据自身业务需要，设置自己的留存时间
- 从保存消息方面来考量的话，下面这组参数是非常重要的：
  - retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。
  - retention.bytes：规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的 Kafka 集群中会有用武之地。当前默认值是 -1，表示可以无限使用磁盘空间。
- 如果从能处理的消息大小这个角度来看的话
  - 有一个参数是必须要设置的，即max.message.bytes。它决定了 Kafka Broker 能够正常接收该 Topic 的最大消息大小
- 怎么设置 Topic 级别参数吧
  - 创建 Topic 时进行设置
    - Kafka 开放了kafka-topics命令供我们来创建 Topic 即可。
    - 对于上面这样一条命令，请注意结尾处的--config设置，我们就是在 config 后面指定了想要设置的 Topic 级别参数
  - 自带的命令kafka-configs来修改 Topic 级别参数
JVM 参数
- Kafka 服务器端代码是用 Scala 语言编写的，但终归还是编译成 Class 文件在 JVM 上运行，使用Java 8
- JVM 端设置，堆大小这个参数至关重要
  - 将你的 JVM 堆大小设置成 6GB 吧，这是目前业界比较公认的一个合理值
  - 我见过很多人就是使用默认的 Heap Size 来跑 Kafka，说实话默认的 1GB 有点小
- JVM 端配置的另一个重要参数就是垃圾回收器的设置，也就是平时常说的 GC 设置
  - 如果你依然在使用 Java 7，那么可以根据以下法则选择合适的垃圾回收器：
    - 如果 Broker 所在机器的 CPU 资源非常充裕，建议使用 CMS 收集器。启用方法是指定-XX:+UseCurrentMarkSweepGC。
    - 否则，使用吞吐量收集器。开启方法是指定-XX:+UseParallelGC。
  - 当然了，如果你已经在使用 Java 8 了，那么就用默认的 G1 收集器就好了
- 我们确定好了要设置的 JVM 参数，我们该如何为 Kafka 进行设置呢
  - KAFKA_HEAP_OPTS：指定堆大小。
  - KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。
  - 比如你可以这样启动 Kafka Broker，即在启动 Kafka 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.shconfig/server.properties
操作系统参数
- 来聊聊 Kafka 集群通常都需要设置哪些操作系统参数
  - 文件描述符限制
  - 文件系统类型
  - Swappiness
  - 提交时间
- 首先是ulimit -n
  - 通常情况下将它设置成一个超大的值是合理的做法，比如ulimit -n 1000000
- 其次是文件系统类型的选择
  - 这里所说的文件系统指的是如 ext3、ext4 或 XFS 这样的日志型文件系统
  - 根据官网的测试报告，XFS 的性能要强于 ext4，所以生产环境最好还是使用 XFS
- 第三是 swap 的调优
  - 因为一旦设置成 0，当物理内存耗尽时，操作系统会触发 OOM killer 这个组件，它会随机挑选一个进程然后 kill 掉，即根本不给用户任何的预警
  - 但如果设置成一个比较小的值，当开始使用 swap 空间时，你至少能够观测到 Broker 性能开始出现急剧下降，从而给你进一步调优和诊断问题的时间
  - 基于这个考虑，我个人建议将 swappniess 配置成一个接近 0 但不为 0 的值，比如 1
- 最后是提交时间或者说是 Flush 落盘时间
  - 这里稍微拉大提交间隔去换取性能还是一个合理的做法
  - 向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功
  - 而是只要数据被写入到操作系统的页缓存（Page Cache）上就可以了
  - 随后操作系统根据 LRU 算法会定期将页缓存上的“脏”数据落盘到物理磁盘上
  - 这个定期就是由提交时间来确定的，默认是 5 秒