跳到主要内容

MQ

为什么使用MQ？​

-解耦：假设现在，日志不光要插入到数据库里，还要在硬盘中增加文件类型的日志，同时，一些关键日志还要通过邮件的方式发送给指定的人。那么，如果按照原来的逻辑，A可能就需要在原来的代码上做扩展，除了B服务，还要加上日志文件的存储和日志邮件的发送。但是，如果你使用了MQ，那么，A服务是不需要做更改的，它还是将消息放到MQ中即可，其它的服务，无论是原来的B服务还是新增的日志文件存储服务或日志邮件发送服务，都直接从MQ中获取消息并处理即可。这就是解耦，它的好处是提高系统灵活性，扩展性。

  • 异步：可以将一些非核心流程，如日志，短信，邮件等，通过MQ的方式异步去处理。这样做的好处是缩短主流程的响应时间，提升用户体验。
  • 削峰：MQ的本质就是业务的排队。所以，面对突然到来的高并发，MQ也可以不用慌忙，先排好队，不要着急，一个一个来。削峰的好处就是避免高并发压垮系统的关键组件，如某个核心服务或数据库等。

下面附场景解释：

解耦​

场景：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃......

img

在这个场景中，A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？头发都白了啊！

如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。

img

总结：通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，A 系统就跟其它系统彻底解耦了。

异步​

场景：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个 1s，这几乎是不可接受的。

img

一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在 200 ms 以内完成，对用户几乎是无感知的。

如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms 以后就直接返回了。

img

削峰​

场景：每天 0:00 到 12:00，A 系统风平浪静，每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ，每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的，大量的请求涌入 MySQL，每秒钟对 MySQL 执行约 5k 条 SQL。

使用 MQ，每秒 5k 个请求写入 MQ，A 系统每秒钟最多处理 2k 个请求，因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求，每秒钟就拉取 2k 个请求，不要超过自己每秒能处理的最大请求数量就 ok，这样下来，哪怕是高峰期的时候，A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来，就 2k 个请求出去，结果就导致在中午高峰期（1 个小时），可能有几十万甚至几百万的请求积压在 MQ 中。

img

这个短暂的高峰期积压是 ok 的，因为高峰期过了之后，每秒钟就 50 个请求进 MQ，但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说，只要高峰期一过，A 系统就会快速将积压的消息给解决掉。

说说Broker服务节点、Queue队列、Exchange交换器？​

  • Broker 可以看做 RabbitMQ 的服务节点。一般情况下一个 Broker 可以看做一个 RabbitMQ 服务器。
  • Queue: RabbitMQ的内部对象，用于存储消息。多个消费者可以订阅同一队列，这时队列中的消息会被平摊（轮询）给多个消费者进行处理。
  • Exchange: 生产者将消息发送到交换器，由交换器将消息路由到一个或者多个队列中。当路由不到时，或返回给生产者或直接丢弃。

如何保证消息的可靠性？​

分三点：

  • 生产者到RabbitMQ：事务机制和Confirm机制，注意：事务机制和 Confirm 机制是互斥的，两者不能共存，会导致 RabbitMQ 报错。
  • RabbitMQ自身：持久化、集群、普通模式、镜像模式。
  • RabbitMQ到消费者：basicAck机制、死信队列、消息补偿机制。

生产者消息运转的流程？​

  1. Producer先连接到 Broker,建立连接 Connection ,开启一个信道(Channel)。
  2. Producer声明一个交换器并设置好相关属性。
  3. Producer声明一个队列并设置好相关属性。
  4. Producer通过路由键将交换器和队列绑定起来。
  5. Producer发送消息到Broker,其中包含路由键、交换器等信息。
  6. 相应的交换器根据接收到的路由键查找匹配的队列。
  7. 如果找到，将消息存入对应的队列，如果没有找到，会根据生产者的配置丢弃或者退回给生产者。
  8. 关闭信道。
  9. 管理连接。

8.消费者接收消息过程？​

  1. Producer先连接到Broker,建立连接Connection,开启一个信道(Channel)。
  2. 向Broker请求消费响应的队列中消息，可能会设置响应的回调函数。
  3. 等待Broker回应并投递相应队列中的消息，接收消息。
  4. 消费者确认收到的消息,ack。
  5. RabbitMq从队列中删除已经确定的消息。
  6. 关闭信道。
  7. 关闭连接。

生产者如何将消息可靠投递到 RabbitMQ？​

  1. Client发送消息给MQ
  2. MQ将消息持久化后，发送Ack消息给Client，此处有可能因为网络问题导致Ack消息无法发送到Client，那么Client在等待超时后，会重传消息；
  3. Client收到Ack消息后，认为消息已经投递成功。

RabbitMQ如何将消息可靠投递到消费者？​

  1. MQ将消息push给Client（或Client来pull消息）
  2. Client得到消息并做完业务逻辑
  3. Client发送Ack消息给MQ，通知MQ删除该消息，此处有可能因为网络问题导致Ack失败，那么Client会重复消息，这里就引出消费幂等的问题；
  4. MQ将已消费的消息删除。

如何保证RabbitMQ消息队列的高可用?​

RabbitMQ 有三种模式：单机模式，普通集群模式，镜像集群模式。

  1. 单机模式：就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
  2. 普通集群模式：意思就是在多台机器上启动多个RabbitMQ实例，每个机器启动一个。
  3. 镜像集群模式：这种模式，才是所谓的RabbitMQ的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据( 元数据指RabbitMQ的配置数据)还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

Rabbit 消费重复的解决方案​

生产者 --> MQ --> 消费者

两个阶段会出现消息重复

  1. 生产者：生产了多条重复的消息。
  2. 消费者：一条消息被消费者重复消费。

如何解决消息重复消费的问题？

为了保证消息不被重复消费，首先要保证每个消息是唯一的，可以给每个消息携带一个全局唯一的 ID。

  1. 消费者监听到消息后获取 id ，先去查询这个id 是否存在。
  2. 如果不存在，则正常消费消息，并把消息的 id 存入数据库或者 redis 中
  3. 如果存在则丢弃此消息。