kafka不同场景下的参数调优

下面从吞吐量优先、延迟优先、可靠性优先以及可用性优先四个方面，逐一分析 Kafka 应该设置的核心参数以及建议的值。

• num.partitions
  分区个数，设置为与消费者的线程数基本相等。

• batch.size

  批量提交消息的字节数，发送消息累计大小达到该值时才会发送（或者达到linger.ms），默认16k，如果 batch 设置太小，会导致频繁网络请求，吞吐量下降；如果 batch 太大，会导致一条消息需要等待很久才能被发送出去，增加网络延时；建议设置为1M。

• linger.ms

  发送间隔时间，默认是 0，意思就是消息必须立即被发送。如果 linger.ms 设置的太小，会导致频繁网络请求，吞吐量下降；如果 linger.ms 太长，会导致一条消息需要等待很久才能被发送出去，增加网络延时;建议设置为100ms以上。
• compression.type
  压缩类型，默认是 none，不压缩，但是也可以使用 lz4 压缩，效率还是不错的，压缩之后可以减小数据量，提升吞吐量，但是会加大 producer 端的 CPU 开销。
• acks
  应答机制，默认是all（0.8.x之前，默认为1），即等待所有的副本收到消息后再返回成功，可以设置成1,即leader副本确认接收到消息后，生产者会收到返回成功的信息。但如果恰好此时leader失效，该条消息就会丢失。

• buffer.memory

  内存缓冲区大小，默认32M，当消息写入过快或者写入量过大时，Sender 线程来不及处理，造成缓存区堆积，此时会阻塞用户线程，禁止往 kafka 写入消息，一般需要根据业务场景估算一个 buffer_memory 的合理值，建议64M以上。

• fetch.min.bytes
  从broker获取消息的最小字节数，只有大于这个值时，consumer才会拉取消息，默认是1，建议设置为1048576（1M）。
• fetch.max.wait.ms

  当fetch.min.bytes不满足时，从broker获取消息的最大等待时间，默认是500,建议设置为1000。

准实时数据的传输，如弹幕。

• num.partitions
  分区个数，设置为与消费者的线程数基本相等。
• num.io.threads
  默认是8。负责写磁盘的线程数。整个参数值要占总核数的50%。
• num.replica.fetchers
  默认是1。副本拉取线程数，这个参数占总核数的50%的1/3。
• num.network.threads
  默认是3。数据传输线程数，这个参数占总核数的50%的2/3。

• linger.ms
  设置为0，即有消息就发送。
• compression.type
  设置为nonenone。
• acks
  设置为0，异步发送，无需等待任何broker确认。

• fetch.min.bytes
  设置为1，一有消息就消费。
• 线程数

  消费者的并发线程数能满足实时消费的要求，避免积压。

• default.replication.factor
  至少设置为3，2/3机器挂掉够，依然不影响数据的可靠性。
• min.insync.replicas
  当生产者的ack设置为all时，必须满足该数量的副本同步成功后才能继续写入。当default.replication.factor设置为3时，该值建议设置为2。
• unclean.leader.election.enable
  不洁leader选举，默认true，建议设置为false,即不允许不在ISR列表中的broker参加leader的选举，否则会导致已经提交但是还未复制的消息的丢失。

• acks
  设置为all,等待ISR中的所有副本收到数据后再返回成功。
• retries
  重试次数，建议>=3。

• enable.auto.commit

  是否开启自动提交，默认true,在设置为true时与auto.commit.interval.ms（自动提交时间间隔）配合使用，有点是简单，省去了偏移量提交逻辑，缺点是会存在重复消费和消息丢失的情况，在数据可靠性优先的场景下需要设置为false,当事务提交后再提交位移。

• unclean.leader.election.enable
  设置为true,允许不洁的副本当选leader。
• min.insync.replicas
  设置为1。
• num.recovery.threads.per.data.dir
  启动时用于日志恢复和关闭时用于刷新的每个数据目录的线程数，默认为1，建议设置为1，减少重启时加载日志的时间。

• acks
  设置为0，不等待任何确认，直接返回成功。

END