问题起因
在一次实际业务中,kafka作为消费者,监听生产者的topic,该项目采用微服务架构为两个实例,但发现消费者消费不到topic的消息,很是疑惑。
问题方案
根据代码日志分析,topic的消息确实已被消费,但是并不是真正的消费者所消费。通过分析和思考后,决定采用在日志中添加实例机器的IP,通过这种方式来提示消息被那台机器消费。
问题解决
项目部署在docker容器中,只能采用查看日志的方式,定位具体问题的产生原因。通过具体实例IP的日志发现,topic消息被UAT(仿生产环境消费),具体定位问题根源:UAT环境(spring.profiles.active=pro),该配置读取了生产环境的apollo配置,导致多实例消费节点增加,kafka消息在负载均衡的过程中,被UAT环境的实例所消费。
最终,问题根源找到,问题彻底解决。
建议:尽量了解消息中间件使用的原理,这样更方便排查和定位问题。