Hi，大家好，我是Mic
一个工作5年的粉丝找到我。
他说： “Mic老师，你要是能答复出这个问题，我就拜服你”
我当场就懵了，当初打赌都这么随便了吗？
我问他问题是什么，他说“Kafka如何防止反复生产的问题！”
上面看看普通人和高手的答复！
普通人：
Kafka怎么防止反复生产就是咱们能够通过 咱们能够在那个音讯生产的这一端就是咱们能够用相似于分布式锁的这样一个设计吧。
我生产一个音讯的时候我能够间接用比如说redis外面的setNx这样一个指令，而后去把那个音讯保留到redis外面而后前面再如果反复发送的话那我就间接只有去判断这个Redis外面有没有存在就好了。
高手：
好的，对于这问题，我从几个方面来答复。
首先Kafka Broker上存储的音讯，都有一个Offset标记。
而后kafka的消费者是通过offSet标记来保护以后曾经生产的数据，
每生产一批数据，Kafka Broker就会更新OffSet的值，防止反复生产。
默认状况下，音讯生产完当前，会主动提交Offset的值，防止反复生产。
Kafka生产端的主动提交逻辑有一个默认的5秒距离，也就是说在5秒之后的下一次向Broker拉取音讯的时候提交。
所以在Consumer生产的过程中，应用程序被强制kill掉或者宕机，可能会导致Offset没提交，从而产生反复提交的问题。
除此之外，还有另外一种状况也会呈现反复生产。
在Kafka外面有一个Partition Balance机制，就是把多个Partition平衡的调配给多个消费者。
Consumer端会从调配的Partition外面去生产音讯，如果Consumer在默认的5分钟内没方法解决完这一批音讯。
就会触发Kafka的Rebalance机制，从而导致Offset主动提交失败。
而在从新Rebalance之后，Consumer还是会从之前没提交的Offset地位开始生产，也会导致音讯反复生产的问题。
基于这样的背景下，我认为解决反复生产音讯问题的办法有几个。
- 进步生产端的解决性能防止触发Balance，比方能够用异步的形式来解决音讯，缩短单个音讯生产的市场。或者还能够调整音讯解决的超时工夫。还能够缩小一次性从Broker上拉取数据的条数。
- 能够针对音讯生成md5而后保留到mysql或者redis外面，在解决音讯之前先去mysql或者redis外面判断是否曾经生产过。这个计划其实就是利用幂等性的思维。
以上就是我对这个问题的了解。
总结
反复生产这个问题很重要，如果没有思考到就会呈现线上的数据问题。
所以在面试的时候，这些问题也可能考查求职者的技术能力以及实际能力。
另外，对于幂等性的问题，我在后面的视频外面有讲，大家能够本人找一找。
喜爱我的作品的小伙伴记得点赞和珍藏加关注。
版权申明：本博客所有文章除特地申明外，均采纳 CC BY-NC-SA 4.0 许可协定。转载请注明来自Mic带你学架构！
如果本篇文章对您有帮忙，还请帮忙点个关注和赞，您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货！