记一次生产kafka消息消费的事故

事故背景:

  我们公司与合作方公司有个消息同步的需求,合作方是消息生产者,我们是消息消费者,他们通过kafka给我们推送消息,我们实时接收,然后进行后续业务处理。昨天上午,发现他们推送过来的广场门店信息我们都没有消费,导致我们系统和他们系统数据不一致,从而导致无法提单,无法出报表(报表有误)等各种问题

排查过程:

(1)因为coco身体不适,上午请假去医院了,所以这个问题就转给我们team的专门运维的同事了,电话大概给他说明了代码路径,可惜,半天下来仍然无果,看着微信群里他发的消息,我有点抓狂,根本没有找到点上,半天了没查出原因,我们业务端也顶着压力,一个劲儿地给我打电话。

(2)中午12:30点,coco回到公司,立马开电脑开始排查,让他们重新推送消息,查看日志,发现我们根本没有消费到。初步判断,应该不是我们客户端的问题,初步定位原因:a.网络问题;b.网络丢包;c.生产者生产机制有问题,实际没有推送过来。

(3)因为之前一直是好好的,近期这个需求也没有做过任何改动,网络也是通的,感觉可能不是网络的问题,但是也要排查,因为这个已经是去年年初的需求了,原熟悉这块业务的人早已离职,所以排查起来有点慢。我们公司在合作公司面前又没多大话语权,每次有问题都是直接甩锅给我们,每次排查出来都是他们的问题。这次,我让他们先排查自身问题,他们依然说,不是他们的原因等等。

(4)网络排查:根据代码,查出我们连接生产者zookeeper的集群地址。然后我找到我们应用所在主机IP。ping了下是通的。但是telnet端口的时候明显就不通了,很明显的网络问题啊。截图给对方,他们依然不认,说自己测试都是ok的,coco此时心里真的是一万个mmp啊,然而,脸上还要笑嘻嘻……为啥之前一直通的,突然就有问题了呢,让对方研发问他们那边最近有没有做过网络调整,那哥们直接说没有……涉及公司与公司间的网络权限,肯定要走流程去申请啦。我就去找我们这边网络组的老大,把事故简要地说明了下,他说,合作方公司前几天有下线过一批主机呀,我联系他们,包不包含这几台,此刻,我的心里大石头终于放下了,找对人了。

ping的结果:

telnet的结果:

(5)后来,在这个leader、我们项目经理的协调下,找了对方公司的网管,确认是他们近期做了网络调整导致的。然后,对方公司对接人去提了网络申请,该问题算是初步得到了解决,下午2:40左右,网络给打开了,把这几天的存量数据又重新推送了一次。

结论:

对于生产正在用的接口,一直好好的,突然出问题,如果是全量问题,首先要排查网络问题,如果是部分数据有问题,则要考虑是否是网络丢包,是否是消息丢失。

复盘:

其实,这个问题真的从根源上解决了吗?并没有,根据生产日志,查询得知,自6.5日开始,就没有消费过消息了,说明6.5号就有问题了啊。我们系统也没有报异常,没有通知到负责人,为什么消费者连不上生产者zookeeper主机的时候,仍不报异常呢,这个coco还在排查。

  ConsumerConfig conf = new ConsumerConfig(props);
  //连不通但是没有报异常
  ConsumerConnector consumer = kafka.consumer.Consumer.createJavaConsumerConnector(conf);

 代码:

原文地址:https://www.cnblogs.com/cocoxu1992/p/11007846.html

时间: 2024-10-19 08:59:28

记一次生产kafka消息消费的事故的相关文章

rabbitMQ应用,laravel生产广播消息,springboot消费消息

最近做一个新需求,用户发布了动态,前台需要查询,为了用户读取信息响应速度更快(MySQL很难实现或者说实现起来很慢),所以在用户动态发布成功后,利用消息机制异步构建 redis缓存 和 elasticsearch索引 . 开发环境 rabbitMQ服务端,docker安装 拉取rabbit-mq镜像 docker pull hub.c.163.com/library/rabbitmq:3.6.10-management 运行镜像 docker run -d --name rabbitmq --p

Spring Cloud Stream如何消费自己生产的消息

在上一篇<Spring Cloud Stream如何处理消息重复消费>中,我们通过消费组的配置解决了多实例部署情况下消息重复消费这一入门时的常见问题.本文将继续说说在另外一个被经常问到的问题:如果微服务生产的消息自己也想要消费一份,应该如何实现呢? 常见错误 在放出标准答案前,先放出一个常见的错误姿势和告警信息(以便您可以通过搜索引擎找到这里^_^).以下错误基于Spring Boot 2.0.5.Spring Cloud Finchley SR1. 首先,根据入门示例,为了生产和消费消息,需

kafka 消息服务

apache kafka参考 http://kafka.apache.org/documentation.html 消息队列方式: 点对点: 消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息.这里要注意: 消息被消费以后,queue中不再有存储,所以消息消费者不可能消费到已经被消费的消息. Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费. 发布/订阅: 消息生产者(发布)将消息发布到topic中,同时有多个消息消费者(订阅)消费该消息

Kafka消息的可靠性测试--针对直播业务的方案选择

转自:http://blog.csdn.net/bailove/article/details/44240303 业务场景 来疯直播互动平台,每天有数百万人上下线,有数十万人同时参与互动直播聊天.用户的登陆.退出及用户间的各种交互行为如聊天.送礼.关注.投票.抢沙发等等事件都会产生大量的消息.这些消息具有瞬间爆发性,比如热门直播间刚开播,直播表演的高潮等等.而用户的礼物.星星.喇叭.沙发等这类消息是不允许丢失,必须100%送达.这就需要有一个高性能,高可靠,稳定可拓展的消息服务平台的支撑.它要求

Hadoop学习笔记-011-CentOS_6.5_64_HA高可用-Zookeeper3.4.5安装Kafka+消息监控KafkaOffsetMonitor

参考: http://www.cnblogs.com/smartloli/p/4538173.html http://blog.csdn.net/lsshlsw/article/details/47342821 虚拟机中共五个centos系统,每个系统有两个用户root和hadoop:cdh1,cdh2,cdh3,cdh4,cdh5 集群规划 安装kafka(cdh3机器) 第一步,解压已下载好的kafka安装包 #tar -zxvf kafka_2.9.2-0.8.2.2.tgz 解压后删除k

apache kafka消息服务

apache kafka中国社区QQ群:162272557 apache kafka参考 http://kafka.apache.org/documentation.html 消息队列分类: 点对点: 消息生产者生产消息发送到queue中,然后消息消费者从queue中取出并且消费消息.这里要注意: 消息被消费以后,queue中不再有存储,所以消息消费者不可能消费到已经被消费的消息. Queue支持存在多个消费者,但是对一个消息而言,只会有一个消费者可以消费. 发布/订阅 消息生产者(发布)将消息

Kafka实战:如何把Kafka消息时延秒降10倍

背景 中软独家中标税务核心征管系统,全国34个省国/地税.电子税务局15省格局.大数据×××局点,中国软件电子税务局技术路径:核心征管 + 纳税服务 业务应用分布式上云改造. 业务难题 如上图所示是模拟客户的业务网页构建的一个并发访问模型.用户在页面点击从而产生一个HTTP请求,这个请求发送到业务生产进程,就会启动一个投递线程(Deliver Thread)调用Kafka的SDK接口,并发送3条消息到DMS(分布式消息服务),每条消息大小3k,需要等待3条消息都被处理完成后才会返回请求响应⑧.当

Kafka无法消费!?究竟是bug的“沦陷”还是配置的“扭曲”?

在一个月黑风高的夜晚,突然收到现网生产环境Kafka消息积压的告警,梦中惊醒啊,马上起来排查日志.问题现象消费请求卡死在查找Coordinator Coordinator为何物?Coordinator用于管理Consumer Group中各个成员,负责消费offset位移管理和Consumer Rebalance.Consumer在消费时必须先确认Consumer Group对应的Coordinator,随后才能join Group,获取对应的topic partition进行消费. 那如何确定

Kafka消息模型

一.消息传递模型 传统的消息队列最少提供两种消息模型,一种P2P,一种PUB/SUB,而Kafka并没有这么做,巧妙的,它提供了一个消费者组的概念,一个消息可以被多个消费者组消费,但是只能被一个消费者组里的一个消费者消费,这样当只有一个消费者组时就等同与P2P模型,当存在多个消费者组时就是PUB/SUB模型. Kafka 的 consumer 是以pull的形式获取消息数据的. pruducer push消息到kafka cluster ,consumer从集群中pull消息,如下图.该博客主要