每天晚上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集群的同事，报警没加上[汗]。
相信问题解决到这个程度，下次再遇到这种问题，搜索的哥哥们下次就不会第一时间来找我了。下次沟通估计就是我出差回来给他们带吃哒[胜利][胜利]
