RabbitMQ的优缺点
优点
这边的流量削峰功能主要应用在秒杀活动中，在秒杀活动中一般因为流量过大，导致应用挂掉，为了解决这个问题，在应用前端、库存系统前端加入消息队列，在订单系统中，服务器收到用户的请求后，首先写入消息队列，超过消息队列的长度的用户请求，则被直接抛弃或者跳转到错误页面，这样可以控制活动人数；在接下来秒杀业务处理系统根据消息队列中的请求信息可以按照自己的最大处理能力获取订单，能有效的避免短时间内高流量涌入压垮应用的问题。
一般用户在下单成功后订单系统户调用库存系统来进行库存的减少，传统做法是下单成功后直接调用库存系统，这样做有两个问题：一.当库存系统出现问题就导致下单失败。二.订单系统和库存系统耦合性高。但是当我们引入RabbiMQ后，订单系统只需要把订单信息进行持久化，把消息存入消息队列，返回给用户下单成功的信息。对库存系统来说就是订阅下单信息，从消息队列中获取下单消息来进行库存的修改，当库存系统出现问题也会因为消息队列能保证消息的可靠投递，不会导致消息的丢失。
就订单系统而言，下单成功后需要调用短信接口给用户发送下单成功的短信，一般的做法是在下单成功后直接调用短信接口给用户发送短信，但是如果调用的接口或者短信运营商出现问题，就会造成下单过程的阻塞，导致整个下单流程的不成功。我们引入RabbitMQ后可以对像发短信这样的不是必须的业务逻辑进行异步处理，就能有效的避免下单过程的阻塞。
应用异步
对系统解耦
对高并发流量进行削峰
缺点
A系统处理成功后直接返回成功，接收到消息BC系统也写库成功，但是D系统处理写库失败，这个时候就造成了数据的不一致问题。
系统增加了外部依赖越多，容易挂掉
举例：以前是A系统直接调用BCD系统，现在在中加入了MQ，加入MQ挂掉了那整套系统就崩溃了。
需要处理消息丢失
消息的重复消费
有些系统会对消息的顺序有要求这样就需要针对各队系统对消息顺序传递性问题的处理
增加系统的复杂性
系统可用性降低
一致性问题
如何保证消息队列的高可用
(1)RabbitMQ的高可用性
RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。
rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
1)单机模式
就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
2)普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
3)镜像集群模式
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
那么怎么开启这个镜像集群模式呢？我这里简单说一下，避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
