深入理解Kafka的核心调优参数
kafka的配置属性多达几百个，在生产环境中对kafka进行调优时，该如何设置这些属性值呢？
调优之前，首先需要对业务场景进行分析，确定业务是吞吐量优先，还是对延时优先，是对可靠性要求比较高，还是对可用性要求比较高，然后再根据分析的结果，在吞吐量、延时、可靠性和可用性4个方面做权衡。
下面分别从吞吐量优先、延时优先、可靠性优先以及可用性优先4个方面，逐一分析kafka应该设置哪些核心属性以及提供建议值。
吞吐量优先
吞吐量优先意味着需要尽可能提升每秒发送消息的吞吐量
常见场景：日志收集
压缩类型为什么选择lz4? 因为这种类型的压缩方式下，吞吐量最大。吞吐量优先时，会占用大量的网络带宽，如果不希望影响整个网络，可以设置配额。
低延时优先
低延是指producer开始发送消息到consumer接收到消息的时间差。低延时优先意味着每条消息需要尽可能快地完成端对端（从producer到consumer）的传递
常见场景：近实时数据的传输、聊天、视频弹幕等应用
优化durability
可靠性就是要降低丢失消息的概率。最常见的做法就是通过消息复制实现高可靠。
必须调用producer的close()方法，该方法会一直block，直到之前发送的消息全部发送成功 retries>0 & max.in.flight.requests.per.connection>1 会产生消息reordering
- default.replication.factor和min.insync.replicas的区别 default.replication.factor是指分区的总的副本个数，min.insync.replicas是指ISR列表中最少的在线副本的个数（含leader）,当在线的副本个数小于min.insync.replicas时，生产者发送消息会失败。default.replication.factor=3，min.insync.replicas=2表示消息总共有3个副本，当在线的副本大于或者等于2时，生产者可以继续发送消息，能够容忍1个备份不可用，否则不能发送消息。
推荐配置：每个分区一个物理存储磁盘，每个分区一个consumer
- retries 自动重试
重试的副作用
- 重复消息；集群出现短暂失败时可能会导致重复消息，需要消费者端自己处理重复消息；另外exactly once semantics (EOS) 的功能还在开发中，这种机制可以保证无重复消息。
- 导致消息重排；为了保证消息有序并且允许重新发生失败的消息，需要将max.in.flight.requests.per.connection设置为1，从而保证任何时候只有一个消息发送到broker。
优化availability
提高可用性，就需要在kafka出现故障时，能够尽快地恢复。
acks对吞吐量、延时和可靠性的影响
消息大小TIPs
fetch.message.max.bytes(consumer default:1MB)>message.max.bytes(broker，default:1000000 0.96M)，否则消息过大不能被消费，导致consumer被hang住。
replica.fetch.max.bytes(broker)>message.max.bytes(broker)，否则消息过大导致broker复制消息失败，存在消息丢失的风险
版权声明：
本文为《大数据真好玩》整理，原作者独家授权。未经原作者允许转载追究侵权责任。
编辑｜冷眼丶