本文转载自微信公众号《猿世界》，作者尹继焕。转载本文请联系元天地公众号。有读者告诉我，最近去某公司面试，面试官要问他MQ挂了怎么办？读者说当时挺迷茫的，因为平时工作没有想过这样的问题，所以回答：挂了就报错，立马重启，还有什么办法做。其实这个问题并不是说面试官是一种狂妄的行为，因为MQ确实有可能挂掉，这是很正常的现象。只是这个挂掉的概率很小，毕竟都是集群模式。如果你平时和朋友、同事聊起这个问题，不管怎样都可以回答。如果是在面试过程中，最好仔细想想怎么回答，不要太随意，否则面试结果可能不会那么理想。第一步：统一封装MQ的操作。如果MQ挂了，势必会影响你发送消息的逻辑。我们可以仔细思考这个问题。MQ不像数据库。如果挂了，就无法进行任何操作。MQ本身用于多系统解耦，异步处理等场景。即使MQ挂了，也不会影响到主进程。所以这其实相当于一个降级过程，没什么特别的。要进行降级处理，必须统一处理。不可能每一个发消息的地方都去处理，只有豆瓣会做。所以第一步先统一MQ操作，然后在这个包里面做一个统一的降级逻辑，不要让用户关注到你的降级逻辑。第二步：降级处理。有两种方法可以降级数据存储。一种是将要发送的消息存储在数据库中，另一种是直接写入本地磁盘。写入数据库写入数据库比较简单。该数据库将在程序本身中使用。这时候只需要单独添加一张表即可。当消息发送异常时，消息被存储。写入磁盘写入磁盘与数据库具有相同的功能。写入磁盘相对独立，不依赖于数据库。不好的一点是写入磁盘时，还必须考虑写入的格式。比如大量的消息是否应该写在多个文件中，比数据库整体要考虑的点更多。写日志写日志可能是最简单的方式，但是后面重发消息时，需要人工干预，把失败的消息捞出来重发。第三步：重发消息，可以单独设置一个定时任务，定时重发这些失败的存储消息。如果你的MQ服务在失败后几分钟内恢复，那么当你重试发送出去时消息就会成功。也可以手动处理。最重要的是，当MQ出现故障时，消息是发不出去的。这些消息必须存储起来，不能丢失。这是关键点。完整的过程如下：总结本文只是给大家提供一些思路。其实任何对中间件的依赖都需要考虑异常情况以及如何回滚。当然最重要的还是监控，这样在出现故障后能及时发现问题，快速修复。然后加入自下而上的回退逻辑，重新发送失败的消息，保证业务的完整性。作者简介：尹继焕，单纯的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》、《Spring Cloud微服务 入门 实战与进阶》的作者，公众号猿世界的创始人。原文链接：http://cxytiandi.com/blog/user/1
