为什么要使用消息队列/消息队列的应用场景

消息队列的主要作用是：解耦、异步、削峰。

解耦
如果A系统要发送数据给B、C、D三个系统，之后可能还有系统加进入进来，我们用消息队列的话A系统只管把消息发到消息队列，其他需要这个消息的来订阅就可以了，
异步
A 系统需要发送个请求给 B 系统处理，由于 B 系统需要查询数据库花费时间较长，以至于 A 系统要等待 B 系统处理完毕后再发送下个请求，造成 A 系统资源浪费。使用消息队列后，A 系统生产完消息后直接丢进消息队列，不用等待 B 系统的结果，直接继续去干自己的事情了。
削峰
A 系统调用 B 系统处理数据，如果A系统的请求突然变得特别大全都打到B系统，那B系统可能就会崩掉。我们让A系统把请求发到消息队列，这样B系统就可以按自己的需求去拉取消息进行消费。

使用了消息队列会有什么缺点

降低系统的可用性：系统引入的外部依赖越多，越容易挂掉；
系统复杂度提高：使用 MQ 后可能需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题；
一致性问题：A 系统处理完了直接返回成功了，但问题是：要是 B、C、D 三个系统那里，B 和 D 两个系统写库成功了，结果 C 系统写库失败了，就造成数据不一致了。

如何保证消息队列是高可用的

不同的消息队列的方式不同

RocketMQ是如何保证消息队列是高可用的

rocketmq是通过broker主从机制来实现高可用的。相同broker名称，不同brokerid的机器组成一个broker组，brokerId=0表明这个broker是master，brokerId>0表明这个broker是slave。

消息生产的高可用：创建topic时，把topic的多个message queue创建在多个broker组上。这样当一个broker组的master不可用后，producer仍然可以给其他组的master发送消息。 rocketmq目前还不支持主从切换，需要手动切换
消息消费的高可用：consumer并不能配置从master读还是slave读。当master不可用或者繁忙的时候consumer会被自动切换到从slave读。这样当master出现故障后，consumer仍然可以从slave读，保证了消息消费的高可用

RocketMQ集群部署模式：

单个 Master
多 Master 模式（2m-noslave）
多 Master 多 Slave 模式，异步复制（2m-2s-async）
每个 Master 配置一个 Slave，有多对Master-Slave，HA。采用异步复制方式，主备有短暂消息延迟，毫秒级。
　　优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master 宕机后，消费者仍然可以从 Slave消费，此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
　　缺点：Master 宕机，磁盘损坏情况，会丢失少量消息。
多 Master 多 Slave 模式，同步双写（2m-2s-sync）
每个 Master 配置一个 Slave，有多对Master-Slave，HA。采用同步双写方式，主备都写成功，向应用返回成功。
　　优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
　　缺点：性能比异步复制模式略低，大约低10%左右，发送单个消息的RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。

如何保证消息不被重复消费/如何保证消息消费的幂等性

造成重复消费的原因：
消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。而因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。
解决依据场景而言：

拿到这个消息做数据库的insert操作
给这个消息做一个唯一的主键，那么就算出现重复消费的情况，就会导致主键冲突
你拿到这个消息做redis的set的操作
这种情况不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作
给消息分配一个全局id，在业务中通常是具备唯一业务标识的字符串，如：订单号、流水号等。且一般由生产者端生成并传递给消费者端。

如何保证消费的可靠性传输

每种MQ都要从三个角度来分析：

生产者弄丢数据
消息队列弄丢数据
消费者弄丢数据

RocketMQ如何保证消费的可靠性传输

生产阶段
不管是同步还是异步的方式，都会碰到网络问题导致发送失败的情况。针对这种情况，我们可以设置合理的重试次数，当出现网络问题，可以自动重试。
存储阶段
- 将消息保存机制修改为同步刷盘方式
- 集群部署方式采用一主（master）多从（slave）部署方式
  默认采用异步的方式，为了进一步提高消息的可靠性，我们可以采用同步的复制方式，master节点将会同步等待 slave 节点复制完成，才会返回确认响应。
消费阶段
如果 Broker 未收到消费确认响应或收到其他状态，消费者下次还会再次拉取到该条消息，进行重试。

结合生产阶段与存储阶段，若需要严格保证消息不丢失，broker 需要采用如下配置：
在这里插入图片描述
同时这个过程我们还需要生产者配合，判断返回状态是否是 SendStatus.SEND_OK。若是其他状态，就需要考虑补偿重试。

RabbitMQ如何保证消费的可靠性传输

在这里插入图片描述

生产者丢数据
从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
- transaction机制就是说，发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降。
- confirm 机制。一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了。如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。
消息队列丢数据
开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
消费者丢数据
消费者丢数据一般是因为采用了自动确认消息模式。这种模式下，消费者会自动确认收到信息。这时rabbitMQ会立即将消息删除，这种情况下，如果消费者出现异常而未能处理消息，就会丢失该消息。
至于解决方案，采用手动确认消息即可。