ActiveMQ火墙连接测试扯皮记

测试中心在前几周发现客户端到ActiveMQ的连接建立了超过6W个,且都是Establish状态,导致了火墙的CPU飙高到了99%。主要问题是客户端上并没有使用重连连接的逻辑,唯一重连连接的可能就是failover了,但是failover也只是在连接断开后才会进行连接的重建。

因此唯一的可能指向了应用上认为连接断开了,但是系统端的连接实际上并未断开。进一步考虑生产和测试的差异,最大可能是因为MQ的数量太少,导致MQ上负载过大。由于每个客户端建立两个连接,中心一共有6000个客户端,而只有4台4C8G的MQ,暨每个MQ需要承载3000个连接。

呵呵哒……

为了具体定位问题的原因,需要在测试中心重现一下问题,然后拿日志来分析原因。

接着开始漫长的扯皮过程。

测试中心:你不定位问题原因,不能让你开MQ

我:不开MQ我怎么定位问题原因…日志都被冲掉了。(ActiveMQ默认日志是1MB,滚动5次)

测试中心:我这一堆应用,如果再出问题怎么办?

我:这次在网络侧监控着,如果连接数超过了预期,那就立刻用杀进程的方式关闭MQ就行。

测试中心:……

一周后

我:哈喽,上次的方案可行吗?有空看看吗?

测试中心:……

一周后

测试中心:你提个变更申请吧

提完变更申请

测试中心:你这变更可能影响很多业务,我给你把申请退回去,你把应急预案,变更步骤什么的补充下,然后我们来开个会讨论一下。

……

ActiveMQ火墙连接测试扯皮记_第1张图片
皮球踢得漂亮

你可能感兴趣的:(ActiveMQ火墙连接测试扯皮记)