Kafka3.0—生产调优

一、数据相关调优

1.数据可靠性

参数名称	说明
acks=0	生产者发送过来的数据，不需要等数据落盘应答
acks=-1	生产者发送过来的数据，Leader 收到数据后应答
acks=1	生产者发送过来的数据，Leader+和 isr 队列里面的所有节点收齐数据后应答

ack默认值为-1，-1和all效果一样
至少一次（At Least Once）= ack=-1 + 分区副本数>=2 + ISR里应答的最小副本数量>=2
至少一次可能导致数据重复

2.数据去重

参数名称	说明
enable.idempotence	是否开启幂等性，默认 true，表示开启幂等性

只有事务才能保证数据不重复

3.数据有序

单分区内，数据是有序的，这是有条件的：
1）开启幂等性
设置参数max.in.flight.requests.per.connection小于等于5，默认值是5
2）不开启幂等性
设置参数max.in.flight.requests.per.connection为1

4.数据乱序

多个分区和分区间数据是无序的。

二、分区和副本相关调优

1.增加Kafka新节点

服役新节点的步骤：
1）先把新增加的节点配置好启动起来
2）配置要进行再平衡的主题Topic
3）指定可以使用的节点让Kafka自动生成副本存储计划
4）根据生成的副本存储计划创建相应文件然后执行
5）验证副本存储计划是否执行成功

2.减少Kafka节点

退役节点的步骤：
1）配置要进行再平衡的主题Topic
2）指定可以使用的节点让Kafka自动生成副本存储计划
3）根据生成的副本存储计划创建相应文件然后执行
4）验证副本存储计划是否执行成功
5）把不需要的节点下线

3.增加分区

在命令行使用命令即可：bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --alter --topic first --partitions 3
分区数只能增加不能减少

4.手动调整分区副本存储

方式一：自己手动创建副本存储计划
方式二：让Kafka集群为我们生成副本存储计划

三、消费者相关调优

1.消费者再平衡

消费者再平衡指的是coordinate与某个消费者失去连接后要进行消费者再平衡，将原来消费者的工作重新分配。

参数名称	说明
heartbeat.interval.ms	消费者和coordinate之间的心跳时间，默认为3s，这个时间必须要小于session.timeout.ms的1/3
session.timeout.ms	消费者和coordinate之间连接的超时时间，默认为45s，超过这个值，这个消费者被移处消费者组，消费者组进行再平衡
max.poll.interval.ms	消费者处理消息的最大时长，默认为5分钟，超过这个值，消费者被移出消费者组，消费者组进行再平衡
partition.assignment.strategy	消费者的分区分配策略，默认为Range + CooperativeSticky 。Kafka 可以同时使用多个分区分配策略。可以选择的策略包括：Range、RoundRobin、Sticky、CooperativeSticky

四、吞吐量调优（重点）

1.提高生产者的吞吐量

生产者吞吐量四个参数：
1）buffer.memory：发送消息的缓冲区大小，默认值是32M，可以增加到64M
Kafka的客户端发送数据到服务器，不是来一条就发送一条的，而是经过缓冲的，也就是说，通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲的，然后把很多消息收集成一个一个的Batch，再发送到Broker上去的。
buffer.memory用来约束KafkaProducer能够使用的内存缓冲的大小，默认值是32M.
如果buffer.memory设置的太小，可能会导致消息快速的写入到内存缓冲里，但是Sender线程来不及把Request发送到Kafka服务器，会造成内存缓冲很快就被写满。一旦被写满，就会阻塞用户线程，不让继续发送数据了。

2）batch.size：默认是16k。
batch.size指的是一批数据的大小，producer发送消息会先写入本地的缓冲区，当数据量凑成batch.size大小时，才进行发送。如果batch 设置太小，会导致频繁的发送少量数据，吞吐量下降，如果batch设置太大，会导致一条消息要等到很久才能发送出去，增加网络延时。
3）linger.ms：默认是0。
linger.ms指的是如果数据批次大小没有到达batch.size，但是到达了这个参数规定的时间，仍然要去发送数据
4）compression.type：默认是none，不压缩。
可以采用lz4压缩方式，压缩之后可以减少数据量，提升吞吐量，但是会加大producer端的开销，因为要对数据进行压缩操作。

2.增加分区

增加分区可以提高吞吐量

3.提高消费者的吞吐量

1）fetch.max.bytes：默认是50M
fetch.max.bytes指的是consumer一次拉取请求中从Kafka中拉取的最大数据量，默认值为50M。
这个参数设定的不是绝对的最大值，如果拉取的消息的大小大于该值，那么该消息仍然返回，以确保消费者继续工作。
2）max.poll.records：默认是500条
max.poll.records指的是消费者在一次拉取请求中拉取的最大消息数量，默认值是500条。如果消息的大小都比较小，可以适当调大该参数来提高一定的消费速度。
3）fetch.min.bytes：默认是1B
fetch.min.bytes指的是Kafka再收到Consumer的拉取请求时，如果返回给consumer的数据量小于这个参数的值，就需要等待，直到数据量满足这个参数的配置大小，可以适当调大这个参数的值以提高一定的吞吐量，不过这会造成额外的延迟。

五、其他调优

1.Leader Partition负载平衡（建议关闭）

指的是可能发生宕机后，多个Leader位于一个broker中导致负载不均衡。

参数名称	说明
auto.leader.rebalance.enable	默认是 true。自动 Leader Partition 平衡。生产环境中，leader 重选举的代价比较大，可能会带来性能影响，建议设置为 false 关闭
leader.imbalance.per.broker.percentage	默认是 10%。每个 broker 允许的不平衡的 leader的比率。如果每个 broker 超过了这个值，控制器会触发 leader 的平衡
leader.imbalance.check.interval.seconds	默认值 300 秒。检查 leader 负载是否平衡的间隔时间

Leader的选举及其消耗资源和性能，因此尽量不要开启，或者把不平衡比例调高。

2.自动创建主题（建议关闭）

如果broker端配置参数auto.create.topics.enable设置为true（默认为true），那么生产者向一个未创建的肢体发送消息时，会自动创建一个分区数为num.partition（默认值为1）、副本银子为default.replication.factor（默认值为1）的主题。
这种创建主题的方式是非预期的，增加了主题管理和维护的难度，建议设置为false。

3.数据精准一次

1）生产者角度
ack设置为-1 + 幂等性 + 事务
2）broker服务端角度
分区副本数大于等于2 + ISR里最小应答副本数量大于等于2
3）消费者角度
事务 + 手动提交offset（消费者输出的目的地必须支持事务）

4.单条日志大于1M

参数名称	说明
message.max.bytes	默认 1m，broker 端接收每个批次消息最大值
max.request.size	默认 1m，生产者发往 broker 每个请求消息最大值。针对 topic级别设置消息体的大小
replica.fetch.max.bytes	默认 1m，副本同步数据，每个批次消息最大值