1. 背景已经基础知识介绍
消息队列，也就是我们常说的mq(message queue)，是在后端开发中非常常用的一个技术。
1.1 消息队列解决了什么问题
主要解决以下几个问题
1.解耦和
很好理解，两个service本来是直接通信的，现在变成了有个中间人，整个的流程是变长了，但是这两个service之间的耦合度肯定是下降了。逻辑图如下：
有MQ时：
2. 异步通信
很多时候，在一个流程里面有的操作是需要立刻执行的，但是有的操作并不需要立刻执行，比如用户注册之后，需要将用户信息写入数据库，同时给用户的邮箱发送一封邮，在这样一个场景里面，对于注册用户来说，将用户信息存入数据库是必须要马上做的事情，而发邮件这件事情却可以在稍后一点再执行也不会有任何影响。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
3. 峰值处理
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。非常典型的场景，应该是淘宝双11以及京东618的活动，在一整年之中，大部分的时候，对于淘宝和京东来说每天的业务访问量都是比较均衡的，也不会在某一个时刻特别高，但是在这种特殊的一两天，流量会剧增，那么，我的系统是要为满足最大峰值而设计吗，显而易见不是，只需满足平常的需求，然后在流量特别大时借助消息队列的帮助即可。想必淘宝的Rocketmq就一定发挥了这样的作用
4.消息通讯
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。 包含两种：一对一，一对多。
这当中前面三个是重中之重。
2. 为什么使用消息队列，消息队列有什么优点和缺点
为什么要使用消息队列，以及消息队列有什么有点，上一部分的：解耦和，峰值处理，异步通讯等，做了很好的解释。
那么缺点是什么呢，很容易想到肯定是变复杂了，具体如下：
系统可用性降低: 本来其他系统只要运行好好的，那你的系统就是正常的。现在加个消息队列进去，消息队列挂了，你的系统也就不能工作了。
系统复杂性增加: 要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。
3. 如何保证消息队列的高可用，如何保证不被重复消费
承接第二部分，这些问题和缺点我们怎么解决呢？
1.如何保证消息队列的高可用性？
高可用性定义如下：
服务器的可用性是指单位时间内(通常一年)，服务器可以正常工作的时间比例，计量单位是百分比，常用99%,99.9%,99.99%来表示。一般讲4个9，5个9或者6个9。
可用性为99%的系统，全年停机时间为3.5天；99.9%的系统；全年停机时间为8.5小时；99.99%的系统全年停机时间为53分钟；99.999%的系统全年停机时间仅仅约为5分钟
即解决第一个问题，就是消息队列挂了你的系统用不了，我们如何保证消息队列挂了也能工作？
基本思想是，链接一个rabbitmq，如果这一个宕机了，那么就不能工作了，那么很简单，我不用一个rabbitmq来处理，而是用一群来处理，并且部署在多个服务器上，其中一个不工作，也不会影响系统的使用，那么稳定性和安全性自然就提升了。更多的可以参考：https://blog.csdn.net/super_rd/article/details/70856909
2. 如何保证不被重复消费？
