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

　　天天晚上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  谢谢哦~~