java应用容灾方案_Java服务MQ消息队列容灾方案-Go语言中文社区

背景介绍

在前一段时间线上出现过一次事故，一个非常重要的消息生产者服务，由于MQ出现问题，消息大量积压，导致了该服务线程被打满，外部请求返回502，服务采用Springboot搭建，使用Springboot的Tomcat容器。

原因分析

消息的生产者服务是一个高并发量的服务，接受外部方的接口调用，并将消息推送至MQ，调用流程示意图如下：

而事故当天的情况是，MQ消息大量积压，基本等同于MQ挂掉，

大量的请求积压在推送消息到MQ的地方，导致外部的大量的请求在Tomcat的线程池积压，当Tomcat的线程池全部被打满后，服务不能再接受新的请求进入，导致抛出大量的502错误。

容灾方案分析

一、发送消息超时时间设定

首先可以想到的是，在MQ发送消息处，设置推送消息的超时时间，超过超时时间，认为消息发送失败，将消息写入文件中，当时这个方案并没有根本上解决，如果MQ挂掉，Tomcat不被打满的问题，虽然可以解决目前的生产场景的情况，但是当后续请求量更大时候，不能保证Tomcat不被打满，同时，消息推送的超时时间的设定也不好进行把握，如果由于网络波动或其他情况，导致消息推送慢，但是是可以推送成功的，但是万一超过了超时时间，消息直接不会发送，反而会影响目前的业务逻辑。

二、调整Tomcat线程池大小

事故的起因是因为Tomcat被打满，那调整Tomcat的线程池大