离线数据推送问题(消息队列)

  每天晚上9点多我要起身下班的时候,抬眼看到周围还在公司的也就只有几个刚毕业的小鲜肉了,就感觉自己也好年轻啊。虽然不止感觉,其实本来也不老。但是转眼又一想,我晚饭都不吃,每天多比人家工作了好几个小时,但是水平的提高一点也不成正比啊,是不是方法不当啊。唯一成正比的,我确实把身体锻炼好了,骑自行车40公里来上班,中间不停,骑得飞快,整个路程总体还是往高处走的,到公司休息一下正常上班,一点儿感觉都没有。有一种无知叫做不知道什么事情是不可能的,想到就去做了。

  直到中午和我们同事90后MM去吃饭,她最近想在网上做些小生意。我才想到:女孩子最大的劣势在于专注。朋友圈里好多有正式工作的女孩在弄微商,我却没见过一个技术特别好的男同事在弄副业的。我可以同时做很多的事情,确实所有的事情都没有做深入到极致。人所能达到的境界不是和付出的时间成正比,而是和对自己的要求成正比。人的优秀程度是和野心成正比的。我的知足常乐的心,在生活中是件好事,但是工作中却是自己最大的挑战了。和之间同事聊天,他说每天进步一点点就好。我说如果我现在每天只是进步一点点,那么以后的进步就更慢了。这几年中没有一个质的飞越,过几年就更难冲破前进的壁垒,最后是自己以为自己在进步,别人看你只是原地打转。

  今天发生的问题:消息队列报错,实时消息没有发送成功,重启后问题消失。

继续看其他的错误日志:

消息队列采用公司统一的apache qpidd集群。报错的lesocms.video.guoguang.queue这个消费队列。问题很清楚,生产者在我这边,消费者在搜索部门。生产的东西消费者没被消费掉,队列积压了。消费的问题不管是他们消费程序挂了还是消费慢,都已经交给搜索部门去处理了,我这边要解决遇到这种问题怎么处理。

  问题1:队列满了之后尝试了几次后close,只能靠人工重启重置连接的问题

  解决方法: 找到几个关键的异常点

Caused by: org.apache.qpid.transport.SessionException: timed out waiting for sync: complete = -1, point = 0

Exception when sending message:timed out waiting for sync: complete = -1, point = 0

Caused by: org.apache.qpid.transport.SessionClosedException: session closed

Caused by: javax.jms.JMSException: Exception when sending message:session closed

异常刚开始的日志:

定位到刚开始异常的行:

找到异常前后的日志:

发现越往后的日志里,新增大量的 create class:com.letv.mms.transmission.task.sub.SwiftSendMsgTask

我专门查了一下 create class:com.letv.mms.transmission.task.sub.SwiftSendMsgTask的新建数量:

 出问题的这天不断的新建,正常稳定的时候是没有新加的。SwiftSendMsgTask是我当初自己设计的一个对象连接池,目的在于如果消息的发送和正常向消息队列里组装消息是同步的,会造成第一实行性不能保证,因为有的专辑下面有几万个视频,必须组装成一个消息发送,这个消息组装就要好几分钟。第二,组装过程中数据库连接池等待时间过长会自动关闭。所以我就直接异步发消息,从对象连接池中取出一个处理发消息的处理对象扔进去,直接处理下一个。如果处理消息的空闲对象不够用我就直接新建一个放到连接池里。一直想好好总结一下离线数据的程序,因为这个程序整个架构基本上很原始,资源的调度分配都是程序自己控制的,基本没用什么现成的技术。细节处处处体现精巧,每个设计都解决了特定的问题,但是总体去说这个程序,我却很难把这个程序的独到之处用语言表达出来。言归正传:

记得有次开会,组里谁说线上出了什么什么问题,不过倒是没有异常。我不负责那个项目具体不知道,我只是笑着说:“那可能不是真的没有异常,而是异常日志没打好哦。”经常发现自己这句话说的很有道理。上面异常日志截图里面都把.cpp文件的异常都打印出来了,完全可以按图索骥。但是自己就是个写代码的自己知道,异常的说明文字未必准确,最好还是要查源码。查BasicMessageProducer的源码发现,首先这个session是AMQSession。那么它close了,为什么使用到的时候没新建?org.springframework.jms.connection.CachingConnectionFactory的源码里看到reconnectOnException默认是true,也就是说抛出了这个Jms异常理论上是会新建的,除非新建不成功,不成功是因为SwiftSendMsgTask的新建数量太多,超过了设定的<property name="sessionCacheSize" value="700"></property>。那么我要解决的就是SwiftSendMsgTask在异常后不要新建那么多的问题了。

  将原有的一个对象池分成两个,一个是无限制的对象池,使用时即创建。因为这个离线服务半夜有个跑全量的,我会起1000多个线程来跑,但是每次处理数据的线程池是50,因为这个环节要涉及大量CPU计算数据库连接,虽然是高配物理机,而且数据库是专门将线上数据实时复制的一个从库,专门使用(线程数不大于100的时候效率高)。但是是24核CPU,计算量大,线程数大于50会有CPU跑满的风险。但是每个线程会生成独立的数据文件,然后进行gz压缩。gz压缩很耗时,但是消耗的IO资源,释放了CPU,平时的时候跑全量时会存在600多个同时在压缩,所以对这个的对象池无限制。他们问我:为啥你的程序执行的那么快,我的数量小,反而慢了那么多?因为你拷贝完我那一版之后我改了代码[哭笑], 我把很多线程中不需要返回结果的,和大循环中的项都扔到另外的线程池里去啦。

  发消息的单独放到一个有限制的线程池里去管理。本来cacheSize是700,但是发现正常情况下就算数据量突增,100个都不解决问题的话(其实正常情况下会5个负责发消息的,因为消息体最大是4M,发消息是很快的,异步的,扔到exchange中即可,实时也没有什么并发量),媒资程序那边就挂了,异常不会到达这边,折中一下资源,将cacheSize设置为100。程序中创建对象的时候,如果对象池的activeNum个数超过或者等于91个(因为最多会有8个sleeping的),则不会再新建。配了日志报警,到达40个系统会给我发报警邮件。

  问题2:为什么数据量会突增   答案:咨询了一下德伟:最近接了一批短视频。实时的量发生了剧增。所以消费的能力突然不够也是正常的。目前消费者有两个:一个专辑的,一个视频的。但是生产者只有一个,如果专辑或者视频一个发生了突增,会影响到另一个。另外,专辑有的消息体特别大,极端情况下,一个队列也就是能放100多个消息。所以决定将专辑和视频分开,已经和搜索部门的同事达成协议。并提醒他们将队列承载量采用最高配(500M)

。因为发现他们那边现在不是这么做的[汗]。

  问题3:没有收到消息队列溢出的报警

  答案:咨询了管MQ集群的同事,报警没加上[汗]。

  相信问题解决到这个程度,下次再遇到这种问题,搜索的哥哥们下次就不会第一时间来找我了。下次沟通估计就是我出差回来给他们带吃哒[胜利][胜利]

 如需转载,请注上我的原文链接: http://www.cnblogs.com/xiexj/p/6677694.html  谢谢哦~~

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏古时的风筝

为什么你在群里提的技术问题没人回答?

作为一个程序员,把代码写好是本分,但仅仅是写好代码是不够的,工作的过程中总免不了要与别人打交道。几乎隔一段时间,我就会发现有些人身上出现下面的这两个问题。第一个...

1102
来自专栏大数据文摘

涨姿势 | 如何修复硬盘,以及如何避免硬盘损坏

2124
来自专栏進无尽的文章

基础篇-申请开发者账号

我思故我在,下面就总结下我对 iOS开发者账号的申请中所认为的关键点和所以然,而不单单是网上那些方法步骤哦。 苹果开发者账号分三种。

2441
来自专栏java一日一条

电商网站秒杀与抢购的系统架构

在过去的工作中,我曾经面对过5w每秒的高并发秒杀功能,在这个过程中,整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化,会轻而易举地陷入到异常...

1602
来自专栏AI科技大本营的专栏

还原Facebook数据泄漏事件始末,用户信息到底是如何被第三方获取的?

编译 | AI科技大本营 参与 | 张蔚敏 林椿眄 编辑 | 明 明 据美国《纽约时报》和英国《观察者报》消息,一家数据分析公司( Cambridge Anal...

3555
来自专栏张戈的专栏

妹子你真萌:一次心惊肉跳的服务器误删文件的恢复过程

刚在我的订阅里面看到这篇文章,在爆笑之余也让跟我一样的运维农民工们发人深省,所以转过来分享一下。妹子啊妹子,网上找的东西也不能直接照搬啊,太萌了~~哈哈! 作者...

54011
来自专栏Golang语言社区

服务器开发语言比较

下比较的基础都是基于一种编程语言+一定的第三方或者自己编写的网络库和底层进行的,Skynet稍微特殊,但总体比较合适放到比较中来 C# 开发效率:Windows...

55813
来自专栏IT技术精选文摘

ZStack 的伸缩性秘密(一)异步架构

ZStack 核心架构设计使得 99% 的任务异步执行,因此确保了单个的管理节点能够管理十万级的物理服务器,百万级的虚拟机,数万级的并行任务。

962
来自专栏码匠的流水账

2017年终总结

又到了写年终总结的时候了。每当这个时候思绪总是翻江倒海,因为太久没有反思和总结的缘故,一年才总结一次,确实是有点久,欠的账的太多,梳理起来有点费劲。这里依旧还是...

2081
来自专栏腾讯大数据的专栏

拿什么保护你---TDW数据安全

互联网时代,大数据扮演着极为重要的角色;腾讯作为中国最大社交平台,具备最具权威、代表性的互联网大数据。数据平台部TDW作为公司级的海量数据存储和计算平台,集中了...

2248

扫码关注云+社区