1.为什么要用消息队列?

解耦、异步、削峰

  • 解耦: A系统调用B系统、C系统，传统的调用是直接调用，但是当B系统说我不需要你提供数据了，这时候A需要改代码，Ｃ系统说我不需要某个字段了，这时候Ａ也要改代码，如果又多了一个D系统，A又要写代码。为了实现解耦，引入消息队列，Ａ将产生的数据丢到消息队列中，哪个系统需要 哪个系统就去取；
  • 异步: A系统调用B系统，B系统由于某个需要调用第三方接口超时，导致A系统响应速度慢，而B系统的好坏又不会影响业务逻辑，所以可以改为A异步调用B，A将消息丢到消息队列中，B系统订阅消息，实现A的快速响应；
  • 削峰: 当大量流量请求到系统A时，由于数据库的处理能力有限，造成数据库连接异常。使用消息队列，大量请求先丢到消息队列中，系统A使用按批拉数据的方式，批量处理数据，生产中，高峰期短暂的消息积压是允许的。

2.使用消息队列有什么缺点?

  • 系统复杂性增加：加了消息队列，需要保证消息不会重复消费，需要保证消息的可靠性，需要保证消息队列的高可用
  • 系统的可用性降低：如果消息队列挂了，那么系统也会受到影响

3.为什么选用RocketMQ；RocketMQ和ActiveMQ的区别?

RocketMQ模型简单、接口易用，在阿里大规模使用，社区活跃，单机吞吐量10万级，可用性非常高，消息理论上不会丢失；

  • ActiveMQ严格遵循JMS规范，可持久化到内存、文件、数据库，可用性高主要是主从，多语言支持，消失丢失率低；
  • RocketMQ持久化到磁盘文件，可用性非常高，支持分布式，只支持Java，消息理论上不会丢失；

4.MQ能否保证消息必达，即消息的可靠性？

为了降低消息丢失的概率，MQ需要进行超时和重传，以下是MQ的工作流程

  1. MQ-client-sender 发送消息给MQ-server
  2. MQ-server接收到消息后，发送ACK消息给发送方
  3. MQ-client-sender 接收到 ACK消息后，则消息已经投递成功
  4. MQ-server 将消息发送给 MQ-client-receiver
  5. MQ-client-receiver 得到消息处理业务逻辑
  6. MQ-client-receiver 回复 ACK消息给 MQ-server
  7. MQ-server收到 ACK消息，将已消费的消息删除

注意点:

如果上述 步骤2消息丢失或者超时，MQ-client-sender 内的 timer 会重发消息，直到收到 ACK消息，如果重试N次后还未收到，则回调发送失败。需要注意的是，这个过程中 MQ-server 可能会收到同一条消息的多次重发。
对每条消息，MQ系统内部必须生成一个inner-msg-id，作为去重和幂等的依据，这个内部消息ID的特性是：

  • 全局唯一
  • MQ生成，具备业务无关性，对消息发送方和消息接收方屏蔽

如果上述步骤6 消息丢失或者超时，MQ-server 内的 timer 会重发消息，直到 MQ-server 收到ACK消息并且将已消费的消息删除，这个过程也可能会重发多次，MQ-client-receiver 也可能会收到同一条消息的多次重发。
需要强调的是，MQ-client-receiver 回ACK给 MQ-server，是消息消费业务方的主动调用行为，不能由 MQ-client-sender 自动发起，因为MQ系统不知道消费方什么时候真正消费成功。
为了保证业务幂等性，业务消息体中，必须有一个biz-id，作为去重和幂等的依据，这个业务ID的特性是：

  • 对于同一个业务场景，全局唯一
  • 由业务消息发送方生成，业务相关，对MQ透明
  • 由业务消息消费方负责判重，以保证幂等

4.为什么会造成重复消费？

其实无论是哪种消息队列，造成重复消费原因其实都是类似的。正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除。只是不同的消息队列发出的确认消息形式不同，例如RabbitMQ是发送一个ACK确认消息，RocketMQ是返回一个CONSUME_SUCCESS成功标志，kafka实际上有个offet的概念，简单说一下，就是每一个消息都有一个offset，kafka消费过消息后，需要提交offset，让消息队列知道自己已经消费过了。

造成重复消费的原因:因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。

5.如何保证消息不被重复消费？

这个问题针对业务场景来答，分以下三种情况

  1. 如果你拿到这个消息做数据库的insert操作，给这个消息做一个唯一的主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。

  2. 如果你拿到这个消息做redis的set的操作，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。

  3. 如果上面两种情况还不行，准备一个第三方介质，来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以K-V形式写入redis.那消费者开始消费前，先去redis中查询有没有消费记录即可。

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

其实这个可靠性传输，指的就是不能弄丢数据，每种MQ都要从三个角度来分析：

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

1.生产者弄丢数据

从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。

transaction机制就是说，发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）

然而，这种方式有个缺点：吞吐量下降。因为，按照经验，生产上用confirm模式的居多。一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后，rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了。如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

2.消息队列丢数据

处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和confirm机制配合使用，可以在消息持久化磁盘后，再给生产者发送一个Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。

那么如何持久化呢，安装下面这两步即可

  1. 将queue的持久化标识durable设置为true,则代表是一个持久的队列
  2. 发送消息的时候将deliveryMode=2

这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据

3.消费者丢数据

消费者丢数据一般是因为采用了自动确认消息模式。这种模式下，消费者会自动确认收到信息。这时rabbitMQ会立即将消息删除，这种情况下，如果消费者出现异常而未能处理消息，就会丢失该消息。

至于解决方案，采用手动确认消息即可。

7.如何保证消息的顺序性？

针对这个问题，通过某种算法，将需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)。然后只用一个消费者去消费该队列。

8.消息队列积压怎么办？

消息队列积压的影响:

  • 当消费者出现异常，很容易引起队列积压，如果一秒钟1000个消息，那么一个小时就是几千万的消息积压，是非常可怕的事情，但是生产线上又有可能会出现；
  • 当消息积压来不及处理，rabbitMQ如果设置了消息过期时间，那么就有可能由于积压无法及时处理而过期，这消息就被丢失了；

解决方法如下:

  • 不建议在生产环境使用数据过期策略，一是数据是否丢失无法控制，二是一旦积压就很有可能丢失；建议数据的处理都有代码来控制；
  • 当出现消息积压时，做法就是临时扩大consumer个数，让消息快速消费，一般都是通过业务逻辑的手段来完成

其他参考链接