消息队列面试题
为什么要使用消息队列/消息队列的应用场景使用了消息队列会有什么缺点如何保证消息队列是高可用的RocketMQ是如何保证消息队列是高可用的如何保证消息不被重复消费/如何保证消息消费的幂等性如何保证消费的可靠性传输RocketMQ如何保证消费的可靠性传输RabbitMQ如何保证消费的可靠性传输Kafaka如何保证消费的可靠性传输如何保证消息的顺序性RocketMQ处理消息积压问题为什么要使用消息队列/消息队列的应用场景
消息队列的主要作用是：解耦、异步、削峰。
解耦
如果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如何保证消费的可靠性传输
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会立即将消息删除，这种情况下，如果消费者出现异常而未能处理消息，就会丢失该消息。
至于解决方案，采用手动确认消息即可。
Kafaka如何保证消费的可靠性传输
如何保证消息的顺序性
需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。
如果为了吞吐量，有多个消费者去消费怎么办？
RabbitMQ:单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息；
RocketMQ处理消息积压问题
RocketMQ消息积压
全部丢弃：如果这些消息允许丢失，那么此时可以紧急修改消费者系统的代码，在代码里对所有的消息都获取到就直接丢弃，不做任何的处理，这样可以迅速的让积压在MQ里的百万消息被处理掉，只不过处理方式就是全部丢弃而已。临时扩容消费者系统，增加机器来加快消费速度
