一、提升吞吐量(消息积压问题)
提升生产吞吐量:
- buffer.memory:发送消息的缓冲区大小,默认值是 32m,可以增加到 64m。
- batch.size:默认是16k。如果 batch 设置太小,会导致频繁网络请求,吞吐量下降;如果 batch 太大,会导致一条消息需要等待很久才能被发送出去,增加网络延时。
- linger.ms,这个值默认是0,意思就是消息必须立即被发送。一般设置一个 5-100毫秒。如果 linger.ms 设置的太小,会导致频繁网络请求,吞吐量下降;如果 linger.ms 太长,会导致一条消息需要等待很久才能被发送出去,增加网络延时。
- compression.type:默认是 none,不压缩,但是也可以使用 lz4 压缩,效率还是不错的,压缩之后可以减小数据量,提升吞吐量,但是会加大 producer 端的 CPU 开销。
提升消费吞吐量:
- kafka消费能力不足:同时提升分区数量和消费者组的消费者数量(两者缺一不可),保持 消费者数 = 分区数量
- 下游消息处理不及时:如果没有充分利用下游消费者的处理能力,可以提高每批次拉取的消息数量,如默认一次拉取500条可以修改为1000条;也可以一次多拉一点,调整 fetch.max.bytes 大小,默认是 50m
二、提升消息可靠性
确保生产者生产的消息被接收:
• acks 设置为-1 (acks=-1)
• 幂等性(enable.idempotence = true) + 事务
确保broker中的数据高可用:
• 区副本大于等于 2 (–replication-factor 2)
• ISR 里应答的最小副本数量大于等于 2(min.insync.replicas = 2)
确保消费者正确的消费消息:
• 事务 + 手动提交offset(enable.auto.commit = false)。
• 消费者输出的目的地必须支持事务(MySQL、Kafka)。
三、合理设置分区数
- 创建一个只有1个分区的 topic。
- 测试这个topic的producer吞吐量和 consumer 吞吐量。
- 假设他们的值分别是 Tp 和 Tc,单位可以是 MB/s。
- 然后假设总的目标吞吐量是 Tt,那么分区数 = Tt / min(Tp,Tc)。
例如:producer 吞吐量 = 20m/s;consumer 吞吐量 = 50m/s,期望吞吐量 100m/s;
分区数 = 100 / 20 = 5 分区
分区数一般设置为:3-10 个
分区数不是越多越好,也不是越少越好,需要搭建完集群,进行压测,再灵活调整分区个数。
参考文献:https://zhuanlan.zhihu.com/p/371361083
https://blog.youkuaiyun.com/wanger61?spm=1000.2115.3001.5343