MQ(消息队列)

队列是一种先进先出的数据结构。
在Java里边，已经实现了不少的队列了，那为什么还需要消息队列(MQ)这种中间件呢？

把数据放到消息队列叫做生产者
从消息队列里边取数据叫做消费者

1.解耦

然后，现在有系统B和系统C都需要这个userId去做相关的操作

public class SystemA {

    // 系统B和系统C的依赖
    SystemB systemB = new SystemB();
    SystemC systemC = new SystemC();

    // 系统A独有的数据userId
    private String userId = "Java3y";

    public void doSomething() {

        // 系统B和系统C都需要拿着系统A的userId去操作其他的事
        systemB.SystemBNeed2do(userId);
        systemC.SystemCNeed2do(userId);

    }
}

但此时面对的问题是
过了几天系统B的负责人过来了，告诉系统A，不要那个接口，改下源码
系统E的负责人过来了，告诉系统A，需要userId。然后改下源码
又过了几天，系统B的负责人过来了，告诉系统A，不要那个接口。
又过了几天，系统F的负责人过来了，告诉系统A，需要userId。……
于是系统A的负责人，每天都被这给骚扰着，改来改去，改来改去…
还有另外一个问题，调用系统C的时候，如果系统C挂了，系统A还得想办法处理。如果调用系统D时，由于网络延迟，请求超时了，那系统A是反馈fail还是重试？？最后，系统A的负责人，觉得隔一段时间就改来改去，没意思，于是就跑路了。

然后，公司招来一个大佬，大佬经过几天熟悉，上来就说：将系统A的userId写到消息队列中，这样系统A就不用经常改动了，谁爱要谁要，谁也不用关心。

2.异步
没用MQ之前

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

用了MQ后

本来整个请求需要用950ms(同步)
现在将调用其他系统接口异步化，只需要100ms(异步)
3.削峰/限流
没用前：

那多出来的1000个请求，可能就把我们整个系统给搞崩了

这样即便有每秒有8000个请求，那只是把请求放在消息队列中，去拿消息队列的消息由系统自己去控制，这样就不会把整个系统给搞崩。

有利就有弊，使用消息队列有什么问题及解决办法？
1.

所以，当我们项目中使用消息队列，都是得集群/分布式的。要做集群/分布式就必然希望该消息队列能够提供现成的支持，而不是自己写代码手动去实现。
2.

学过Redis的都知道，Redis可以将数据持久化磁盘上，万一Redis挂了，还能从磁盘从将数据恢复过来。同样地，消息队列中的数据也需要存在别的地方，这样才尽可能减少数据的丢失。那存在哪呢？
磁盘？
数据库？
Redis？
分布式文件系统？
同步存储还是异步存储？

哪都有那些MQ呢？
如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等