测试中心在前几周发现客户端到ActiveMQ的连接建立了超过6W个，且都是Establish状态，导致了火墙的CPU飙高到了99%。主要问题是客户端上并没有使用重连连接的逻辑，唯一重连连接的可能就是failover了，但是failover也只是在连接断开后才会进行连接的重建。
因此唯一的可能指向了应用上认为连接断开了，但是系统端的连接实际上并未断开。进一步考虑生产和测试的差异，最大可能是因为MQ的数量太少，导致MQ上负载过大。由于每个客户端建立两个连接，中心一共有6000个客户端，而只有4台4C8G的MQ，暨每个MQ需要承载3000个连接。
呵呵哒……
为了具体定位问题的原因，需要在测试中心重现一下问题，然后拿日志来分析原因。
接着开始漫长的扯皮过程。
测试中心：你不定位问题原因，不能让你开MQ
我：不开MQ我怎么定位问题原因…日志都被冲掉了。（ActiveMQ默认日志是1MB，滚动5次）
测试中心：我这一堆应用，如果再出问题怎么办？
我：这次在网络侧监控着，如果连接数超过了预期，那就立刻用杀进程的方式关闭MQ就行。
测试中心：……
一周后
我：哈喽，上次的方案可行吗？有空看看吗？
测试中心：……
一周后
测试中心：你提个变更申请吧
提完变更申请
测试中心：你这变更可能影响很多业务，我给你把申请退回去，你把应急预案，变更步骤什么的补充下，然后我们来开个会讨论一下。
……
皮球踢得漂亮
网友评论