背景

事情是这样的，生产的单机kafka有两个队列，消息挤压4个亿，磁盘已经超过98%，眼看服务器就要嗝屁了。这可把我们吓得浑身冷汗，激动不已。二话不说，先关机器，删数据，再起机器。然后就要思考到底是什么问题导致的。

改造一

kafka的partion数量太少了，竟然配置的是1，我特么真是服了，谁他么配置的参数。就一个partion。虽然消费者，起了三个服务，但是就一个partion，也只能有一个消费者消费呀。所以，二话不说，改造

首先给partion数量改为了12，
其次，给消费者加了并发4，这样三个服务一共有12个消费线程
这样一改造，消费量大大增加
最后，我把kafka单机升级成了集群

然后就急忙上线了，感觉效果还可以

改造二

还没过几天，消息又挤压了，特么磁盘又差点爆满了。我特么真是欲哭无泪，明明改造地很牛逼，很壮大了。怎么会还有问题呢。二话不说，关机器，删数据，再分析一波。
不看不知道，一看吓一跳，我同事写的消费者，竟然有很奇葩的代码，如果异常了，特么他又把消息给发到队列里了。哎，我好难呀，一群猪队友呀。这不就导致出现了无法解决的异常，然后，一直发，重复的发，不停的发。最后，只能让他们改。
又上线了，感觉好多了。

改造三

又过了几天，虽然正常了，但是，我发现偶尔消息会挤压那么几百条。然后，偶尔就没有挤压，这种现象显然不是太正常，因为我们的入口量很固定的，没道理会有这种现象出现。所以，我还是决定，打烂砂锅，问到底。通过日志发现，偶尔消费者就会rebalance，所谓的rebalance就是某个消费者组的消费者发生了变动，然后让controller重新调整。一般这种变动就是，消费者数量的增减，或者由于超时导致controller判断某个消费者掉线。

经过分析，我决定修改消费者的参数，让消费者不容易出现连接超时的情况。
同时，避免消费者消费消息时间过长，导致超时。

总结

经过三波改造，现在的kafka已经没有出现过任何问题了。nice。