Introduction
Message Queuing wide range of application scenarios, many companies are currently in use, mainstream messaging middleware has ActiveMQ, RabbitMQ, RocketMQ, ZeroMQ, Kafka, etc., ActiveMQ is the oldest MQ, it is the Apache open source project, ZeroMQ is the most fast message queue, RabbitMQ is also very good, RocketMQ Alibaba open source project, has now been donated to the Apache and became a top-level Apache project, Kafka is the highest throughput of messaging middleware, commonly used in processing logs, probably because throughput the reason the amount, ActiveMQ and RabiitMQ of activity getting lower and lower, with RabbitMQ is written in erlang, good performance, although high concurrency erlang language, but the language of the country to play erlang not a lot of people, it is impossible for a middle special pieces away learning a language it (then do not eat), RocketMQ because there are quite a good performance, resistance to over Ali's two-eleven, didodecyl etc. so more and more active, but do not want to control it more messaging middleware are similar, to learn to understand one of the other is always the same
Scenarios
Many MQ application scenarios, the main thing is, asynchronous, clipping, decoupling, which should be learned by heart, the following specific talk about each feature:
1. asynchronous
To give an example of a user registration, enter the registration information submitted, the general system can send text messages to mobile phones, as well as mailbox binding, etc. When a user registers, the process probably looks like this, first save the information to the user database, and then call the messaging interfaces, then call the mailbox interfaces, and finally returned to the client successfully registered information, shown below.
As shown above, a registered actually is the result of a number of processes, of course, another smaller system will not so what's the problem, but imagine if my system suddenly ushered in a large number of people registered (fire), a few one thousand to tens of thousands, it is sure to bring a lot of problems, plus if network congestion and other problems, it may be registered for a long time to return, or are likely to shoot down the database directly, the user experience is not good (I his mother has not yet registered, you let me so disappointed, we still do not fit), in order to retain customers, so it's necessary to introduce the message queue, let's take a look at the introduction of architecture.
引入了消息队列后并不像以前那样顺序执行了（等一个业务先完成，再到下一个），而是通过异步的方式去执行了，我将用户的注册信息投入到消息队列，大家一同去消费，不仅缩短了时间，还避免了许多问题，
2.解藕
啥也不说，直接上个例子，比如我有一个购物系统，它下面有很多子业务，积分啊，库存啊，优惠卷啊，部门等等，当我要要增加一个物流的接口，那么在没有用消息队列的情况下新增一个接口，我又要去改规则，改代码，这他妈谁受得了，一两个还可以，你来几十个，那老子直接跑路了，谁爱干谁去干，老子干不了，如图
如上所示我们看到了弊端，在社会高速发展的情况下，业务是不停在变化的，所以有需求就要改，一直改，一直改，这谁顶得住，这时候，消息队列就派上用场了，加入消息队列后，我们看看有什么变化
从上图可以看出，业务就不耦合了，你有什么需求，我直接发布到消息队列，你订阅了我，你自己拿去用，至于你能不能用，那是你自己的问题，和我这个系统没关，因为我提供了你想要的东西，你不能用是你自己的问题，哈哈，虽然说得有点不负责任，但是这完全是事实，
3.削峰
在这样一个高并发得时代，随着用户得增加，并发量越来越大，数据库得承受能力有限，所以消息队列起到了一个缓冲区的作用，比如一个秒杀系统，在某个秒活动中，同时有5000个人进行秒杀（要根据系统的用户量，像淘宝双十一1秒差不多60万），如果没有引入消息队列，全部请求落到MySQL上，MySQL可能瞬间宕掉（要根据服务器的处理能力），可能你会说加入Redis作为缓存，但是我们说了，任何数据库（关系型和非关系型）都有它的承受能力，而且并不是所有东西都适合放进Redis,所以这时消息队列就扮演了重要的角色，我们看一看没引入消息队列时的情况。
可以看出所有请求都掉在DB上，DB不死谁死啊，显然这样不行，我们看看引入消息队列后的样子
从上图可以看出我们五年引入消息队列后，所有的用户请求并不是全部投放到数据库，而是投放到MQ，然后再投放到消息队列，因为队列是有顺序的，所以就减轻了数据库的压力， 还可以设置队列值的长度，只允许多个消息进入，这是允许的，因为这个社会本来就是弱肉强食的社会，还需要有一定的运气，如果运气不好，在进入消息队列时队列满了，那就是命吧，没有抢到，如果运气好，是第一个进入队列的，那么恭喜你秒杀成功，最好再去买张彩票，说不定就暴富了！
利弊
凡事有好有坏，有得有失，在你得到的时候其实已经在失去，你有女朋友了虽然不再孤单寂寞了，但是你失去了自由（我宁愿不要自由，哈哈）
使用中间件也会带来很多问题：
1.系统的复杂度在上升：比如消息的重复消费，消息的丢失等一堆问题。
2.高可用：比如MQ挂了，我怎么保证消息不丢失，这种问题肯定要搭建MQ集群来保证高可用性
3.事物：怎么保证数据的一致性，肯定要用事物，使用了MQ以后，其实就是分布式事物了，所以还要解决分布式事物这一问题
我们可以看出引入了消息对了其实会有很多问题，上面只是主要的几个，有得必有失，拥有爱情就会丧失自由，想要放纵就必须付出代价
结语：
爱情诚可贵，消息队列价更高。