共计 1247 个字符，预计需要花费 4 分钟才能阅读完成。
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 带你学架构！
如果本篇文章对您有帮忙，还请帮忙点个关注和赞，您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货！
