kafka性能关键参数配置指导

本文为kafka调优过程中主要参数以及参数相关释意，在遇到kafak性能问题时可优先调整一下参数

1.Broker参数指导

KAFKA_HEAP_OPTS:-Xmx6G

    在producer异步发送模式下对内存消耗要求较大，建议修改该参数为-Xmx4G，实际测试中可以进一步调大观察性能选择一个合适的值。

num.io.threads:8

    Broker用来处理磁盘I/O的线程数目，这个线程数目建议设置为磁盘个数*2。

num.network.threads:3

    用于接收并处理网络请求的线程数，默认为3。其内部实现是采用Selector模型。启动一个线程作为Acceptor来负责建立连接，再配合启动num.network.threads个线程来轮流负责从Sockets里读取请求，建议配置为CPU核数加1。

num.partitions:2

    指定由服务端自动创建Topic时的默认分区数。如果对Topic的Partition未做部署规划，由服务端自动创建，则会以此参数创建Partition个数，Partition的数量会直接影响到Kafka集群的吞吐性能。在集群总Partition的数量可控的情况下尽量增大单个Topic的数量可以增加集群的吞吐性能。 建议在创建Topic时根据性能需求规划该参数，使用客户端命令行去规划创建，不建议由Kafka自动创建。

num.replica.fetchers:1

    对于任意(Broker, Leader)元组，都会有replication.factor-1个Broker作为Replica，在Replica上会启动若干Fetch线程把对应的数据同步到本地，而num.replica.fetchers这个参数是用来控制Fetch线程的数量。 一般来说如果发现Partition的ISR当中只有自己一个Partition，且长时间没有新的Replica增加进来时，单个broker上的partition数量较多（上千个以上）时就可以考虑适当的增大这个参数加快复制进度。

default.replication.factor:2

    此参数对应于num.partitions，都是由Kafka自动创建Topic时使用，一般建议在保持默认值2即可。

compression.type:producer

    指定Topic最终的数据压缩方式，如果设置为producer，那么将保留Producer的压缩方式。默认发送不进行压缩，推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。常用的压缩方式是snappy。配置压缩后Consumer端进行消费不需要进行额外的设置可以跟不压缩的消息一样进行数据消费。

zookeeper.connection.timeout.ms

    Broker连接ZooKeeper的超时时间，单位毫秒。现网的网络环境比较复杂，建议将该值调整为90000（90s），以提高Kafka集群的可靠性，避免Broker跟ZooKeeper的连接出现间歇性的出现闪断现象。

zookeeper.session.timeout.ms

    Broker与ZooKeeper之间的会话超时时间，单位毫秒。如果Broker在此时间内未向ZooKeeper上报心跳，则被认为失效。建议调整为90000（90s）。

2.Producer参数配置

producer.type

    建议可靠性要求高的消息配置为sync同步模式发送，可靠性要求低的消息发送配置为async异步模式发送性能较高可靠性低，在异常情况下会丢失部分数据。

request.required.acks

    这个配置可以设定发送消息后是否需要Broker端返回确认。

          0：不需要进行确认，速度最快。存在丢失数据的风险。

         1：仅需要Leader进行确认，不需要ISR进行确认。是一种效率和安全折中的方式。

        all：需要ISR中所有的Replica给予接收确认，速度最慢，安全性最高，但是由于ISR可能会缩小到仅包含一个Replica，所以设置参数为all并不能一定避免数据丢失。

    对于概率统计类应用即使丢失少量数据也不影响统计分析结果建议配置acks为0，可以获得较高的性能；对于对消息要求较高的应用配置acks为all可以获得较高的可靠性但是会大大降低性能。

compression.codec:none

    Message落地时是否采用以及采用何种压缩算法。一般都是把Producer发过来Message直接保存，不再改变压缩方式。

linger.ms:0

    Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送，以此提高吞吐量，而linger.ms则更进一步，这个参数为每次发送增加一些delay，以此来聚合更多的Message。

compression.type:none

    指定producer生成的数据是否进行压缩后发送给服务端（broker）默认发送不进行压缩，推荐配置一种适合的压缩算法（常用snappy，性能较好），可以大幅度的减缓网络压力和Broker的存储压力。

3. Consumer参数配置

num.consumer.fetchers:1

    启动Consumer的个数，适当增加可以提高并发度，以提高数据消费的吞吐量。 对应的需要增大consumer的内存配置。

fetch.min.bytes:1

    每次Fetch Request至少要拿到多少字节的数据才可以返回。 适当增大每次获取的数据可以提高数据消费的吞吐量。该值设置过大又会导致时延过大，需要结合下面一个参数使用。

fetch.wait.max.ms:500

    在Fetch Request获取的数据至少达到fetch.min.bytes之前，允许等待的最大时长。如果该值设置的太大在数据量较小的情况下会导致时延过大。