事情是这样的，小明是一个工作五年的老程序员，半秃着的头已经彰显了他深不可测的技术实力。
这一天，小明收到了领导给过来的一个需求。
领导对小明说：“小明啊，你工作五年了，这个需求我交给你一个人负责很是放心，你可要保质保量按时落地呀”
小明当即立下军令状，拍着胸脯说到：“放心领导，交给我了”
小明承诺之后就开始认真看起了需求，过了五分钟以后，小明一拍脑袋，发现这需求还蛮简单，就是异步发个RocketMQ然后再由下游系统消费去修改Redis的一些信息，于是小明三下五除二，没花几天就把这事给干完了，于是开启了快乐的摸鱼，等待发布的那一天…
发布上线的这一天在小明的摸鱼下很快到来了…
因为部署的服务器很多，然后需要保证兼容性发布，不能直接停机，所以小明采取的是与往日一贯的兼容性发布方案，也就是分批发布。
准备好所有环境数据以后小明就开始发布了。
在重启第一批机器时，令人意想不到的事发生了，生产疯狂打印如下报错信息
吓的小明直接就给回滚了，为此这件事还惊动到了领导，让领导给铺天盖地一顿哐哐哐
接收完领导的批评以后，小明开始认真复盘为什么会出现这样的问题。
于是小明先画了一个简单的事故回顾分析图来帮助自己分析
正常运行时，应用如下图所示
小明看着这幅图仔细思索，突然小明敏锐的察觉到，难道是Redis与RocketMQ的关闭顺序导致的吗？带着这个问题点，小明开启了对应的源码解析之路
小明先是分析了Redis关闭核心源码（注意：案例使用的都是标准的SpringBoot集成Redis）
紧接着小明继续分析了RocketMQ关闭的核心源码（注意：案例使用的都是标准的SpringBoot集成RocketMQ）
然后小明结合上面两个中间件，继而分析了Spring在进行容器关闭时是如何关闭各类bean的
果然就是这个问题导致的，我们再来画一个图来梳理一下这个事故
分析完原因后，小明就开始思考解决方案了，经过几个夜晚的抓耳挠腮以及对Spring源码的阅读，小明终于找到了解决方案
小明是这样来设计的
步骤一、Spring容器启动快完成时会发送一个ContextRefreshedEvent事件，可以通过这个事件把RocketMQ自己注册的DefaultRocketMQListenerContainer类型的bean取出，存放在一个自己装配的config当中，目的是为了可以自己来控制RocketMQ shutDown的时机
（PS：这里是一定要通过这个事件来做的，不要想着通过@Bean去找或者通过实现ApplicationContextAware接口然后拿到ApplicationContext去getBean的方式获取，因为这个执行过程在RocketMQ自己注册DefaultRocketMQListenerContainer的步骤之前，所以你是拿不到的）
拿不到的原因给大家看一下两张源码图
步骤二、在应用进行关闭时一般是接收到了kill -9
或者调用了exit方法，这个时候Spring会在关闭时发出closeEvent事件，而这个事件是在destoryBean之前发出来的，这个时候我们就可以提前主动对所有的DefaultRocketMQListenerContainer进行shutDown了
步骤三、Redis的shutDown这个时候就可以放心的交给Spring自己的destoryBean方法来执行了
最后直接给大家看解决方案的代码
做完这一系列改造之后，于是乎小明再一次信心满满的开始了发布之旅，这一次就很顺利啦，线上没有再出现该类报错问题，顺利的完成了领导布置的任务，经过这件事后小明的实力又变强了几分
