1.应用场景

解耦、异步、流量削峰。

2.引入后的缺点

系统可用性降低。

一旦MQ挂掉不是直接拉跨了。（所以要做高可用，高可用无非就是用集群或备机，双主双从、镜像集群之类的）

系统复杂度提高

比如最主要的消息丢失了怎么办？消息被重复消费如何？怎么保证消费的顺序性？

一致性问题

producer和consumer两端各有自己的本地事务执行，怎么保证一致性？

3.保证高可用

rocketMQ采用双主双从的结构

保存数据的节点被称为broker（有master和slave的分别），其上还有Name Server作为broker的管理者。
broker们会每隔一段时间通过心跳机制把自己的状态同步给name server。
Name server是broker的一个管理者。
producer发消息的时候先问name server，然后nameserver会给一个broker地址，然后producer再发送给broker。

注意broker的从节点是不能接受消息的。

1.生产者通过Name Server发现Broker
2. 生产者发送队列消息到2个Broker主节点
3. Broker主节点分别和各自从节点同步数据
4. 消费者从主或者从节点订阅消息

rabbitMQ主要使用镜像集群来做高可用

4.保证消息不丢失

4.1 分析丢失的环节

情况一：消息生产者没有成功发送到MQ Broker
情况二：消息发送给MQ Broker后，Broker宕机导致内存中的消息数据丢失
情况三：消费者获取到消息，但消费者还没有来得及处理宕机了，但此时
MQ中消息已经删除，消费者重启后不能再消费之前的消息

4.2 解决丢失

1. 消息发送者发送给MQ Broker后，MQ Broker给生产者确认收到
2. MQ收到消息后进行消息持久化
3. 消费者收到消息处理完毕后手动进行ack确认
4. MQ收到消费者ack确认后删除持久化的消息