面试官问你什么是消息队列？把这篇甩给他！

时间飞逝：

•  又过了几天，系统E的负责人过来了，告诉系统A，需要userId。
•  又过了几天，系统B的负责人过来了，告诉系统A，还是重新掉那个接口吧。
•  又过了几天，系统F的负责人过来了，告诉系统A，需要userId。
•  ……

于是系统A的负责人，每天都被这给骚扰着，改来改去，改来改去…….

还有另外一个问题，调用系统C的时候，如果系统C挂了，系统A还得想办法处理。如果调用系统D时，由于网络延迟，请求超时了，那系统A是反馈fail还是重试？？

最后，系统A的负责人，觉得隔一段时间就改来改去，没意思，于是就跑路了。

然后，公司招来一个大佬，大佬经过几天熟悉，上来就说：将系统A的userId写到消息队列中，这样系统A就不用经常改动了。为什么呢？下面我们来一起看看：

系统A将userId写到消息队列中，系统C和系统D从消息队列中拿数据。这样有什么好处？

•  系统A只负责把数据写到队列中，谁想要或不想要这个数据(消息)，系统A一点都不关心。
•  即便现在系统D不想要userId这个数据了，系统B又突然想要userId这个数据了，都跟系统A无关，系统A一点代码都不用改。
•  系统D拿userId不再经过系统A，而是从消息队列里边拿。系统D即便挂了或者请求超时，都跟系统A无关，只跟消息队列有关。

这样一来，系统A与系统B、C、D都解耦了。

2.2 异步

我们再来看看下面这种情况：系统A还是直接调用系统B、C、D

代码如下：

public class SystemA {  
    SystemB systemB = new SystemB();  
    SystemC systemC = new SystemC();  
    SystemD systemD = new SystemD();  
    // 系统A独有的数据  
    private String userId ;  
    public void doOrder() {  
        // 下订单  
          userId = this.order();  
        // 如果下单成功，则安排其他系统做一些事    
        systemB.SystemBNeed2do(userId);  
        systemC.SystemCNeed2do(userId);  
        systemD.SystemDNeed2do(userId);  
    }  
} 

假设系统A运算出userId具体的值需要50ms，调用系统B的接口需要300ms，调用系统C的接口需要300ms，调用系统D的接口需要300ms。那么这次请求就需要50+300+300+300=950ms

并且我们得知，系统A做的是主要的业务，而系统B、C、D是非主要的业务。比如系统A处理的是订单下单，而系统B是订单下单成功了，那发送一条短信告诉具体的用户此订单已成功，而系统C和系统D也是处理一些小事而已。

那么此时，为了提高用户体验和吞吐量，其实可以异步地调用系统B、C、D的接口。所以，我们可以弄成是这样的：

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!