一、提升吞吐量（消息积压问题）
提升生产吞吐量：
- 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.csdn.net/wanger61?spm=1000.2115.3001.5343