先说结论：调整集群参数

# 每当producer写入10000条消息时，刷数据到磁盘 log.flush.interval.messages=10000

# 每间隔1秒钟时间，刷数据到磁盘 log.flush.interval.ms=1000

好久没有更新了，

沣哥给介绍了个对象，也不知道能不能成，看的看不上咱0.0

回归主题，前几天领导给我派了个活，说客户的kafka消费速度有问题，派我出差去排查一下，我到了现场后先梳理了一下数据链路，一个服务(二进制数据流)->kafkatopic1->kafkatopic2->flink->DB

大概的数据链路是这样的。

排查思路：

1.消费数据没有积压

我先是看一下消费数据有没有积压，没有积压就意味着消费是没有问题的，毕竟绝大多数的kafka问题还是消费速度这里。

2.确认问题所在

顺序其实是有问题的，我按照常规思路去排查kafka问题，而忽略了客户本身的猜想，客户觉得kafka的集群有问题。

于是我们使用kafka自带的压测脚本进行测试，发现的确当前的吞吐量和集群配置不相符(5台机器，48c200g)，每台机器的磁盘有9块，客户的要求是吞吐量达到100w条每秒，对应的消费速度就是大约要在150M/s的吞吐速度。

问题解决：

我们看了一下挂在磁盘，发现只用了4块磁盘，其他5块并没有使用，于是把其他5块磁盘也挂了上去。

master到broker网络通信延迟较低，broker之间网络通信不稳定，有时延迟较高，这个需要运维同学去排查了

重点来了，换参数

有些参数没有起效果，所以就不提了，只写有效果的

# 每当producer写入10000条消息时，刷数据到磁盘 log.flush.interval.messages=10000

# 每间隔1秒钟时间，刷数据到磁盘 log.flush.interval.ms=1000

两个都调整了，尤其是把写入数据的那个调的很大，确实非常有效，提升了很大的吞吐量，同时也造成了延迟性的略微提高，这个是没有办法的，因为我们要求的吞吐量太大了，上面一直飞快的向kafka刷盘，这样调整后每次向kafka刷的数据多了，降低了次数，从而很大程度上提高的吞吐。

具体参数的调整还是要具体情况,真实的生产环境才是最有说服力的方法。

实践是检验真理的唯一途径