MQ的相关概念

MQ就是消息队列。遵循FIFO，主要用于上下游传递消息。

为什么要用到MQ

加之前：
image.png

加之后：
image.png

带来的优势：

  1. 应用解耦

image.png
没加之前，一个订单系统要和其他系统交互，如果订单系统和库存系统的交互出现问题，那么其他交互也会被迫中断。耦合性越高，容错性就越低，可维护性也就越低。

加入以后，订单系统将消息发送到MQ，其他系统去MQ中拉取消息即可，如果某个系统与MQ的交互出现问题，不影响其他系统。对于那个出了问题的系统，只需要将系统修复以后，重新去MQ中拉取消息去处理即可。

image.png

  1. 异步提速

没加之前，用户需要等待的时间长
image.png
需要等待所有交互完成。

image.png
加入以后，用户能感知到的时间只有订单系统和MQ的交互时间，以及和DB交互的时间。效率变高。

  1. 削峰填谷

没加之前，请求瞬间增多可能会导致系统崩溃

image.png

加了以后，虽然请求瞬间增多了，但是先放入MQ中，系统一次从MQ中拉取较少的请求进行处理。
image.png

削峰好理解，就是峰值的5000被削了，只能达到1000.

填谷就是，因为一秒处理的请求只有1000，那么即使高峰期过去了，由于消息积压，仍然会有一段时间要每秒处理1000个请求，就是填谷。

image.png

MQ的不足？

  1. 引入外部依赖越多，系统稳定性越差。如果引入了MQ，MQ宕机了，将会对业务造成影响。因此我们需要保证MQ的高可用性。
  2. 系统复杂度提高，在没有引入MQ之前，采取的是同步的方式，安全性高。但是引入MQ以后，采取的是异步的形式，那么就需要防止消息丢失等情况的出现。

常见的MQ产品

image.png

目前ActiveMQ已经用的人比较少了。

Kafka多用于大数据领域，主要做日志收集，可能会丢消息，但是偶尔丢两个消息不是很影响日志收集。

RabbitMQ则号称百分百不丢消息，因此在一些对安全性要求较高的领域，例如银行，金融方面，应用较多。

RabbitMQ简介

基础架构

image.png

  • Broker： 就是RabbitMQ Server，
  • Virtual hosts：类似于不同的命名空间。当多个用户使用同一个MQ server时，划分出多个vhost提供给不同用户使用
  • Connection： 表示的是Producer / Consumer和broker之间的TCP长链接；
  • Channel： 真正意义上用来发送消息的；
  • Exchange： 消息到达broker的第一站，根据分发规则，匹配查询表中的routing key, 从而分发到queue中去。
  • Queue: 消息最终在queue中被consumer取走。
  • Binding：exchange和queue之间的虚拟连接。

6种不同的工作模式

  1. 简单模式

上手简单，但是实际中使用的不多。

image.png

  1. 工作队列模式

consumer之间相互竞争。

image.png
举个例子，12306要发信息给用户：
image.png
加了RabbitMQ以后，12306只管把消息发给RabbitMQ，由不同的短信服务提供商来互相竞争，从RabbitMQ中拉取消息进行处理。

  1. 发布订阅模式

相比于工作队列模式，发布订阅模式多了一个交互机，队列也从一个变成了多个。因此不再是消费者互相竞争，而是生产者发了一个消息，所有订阅了的消费者都能看到这个消息。例如关注了某个UP主的粉丝们。

image.png

  1. 路由模式

也属于发布订阅模式，区别是可以根据消息的不同Routing key来决定要发送到哪个队列中去。

如下图，如果是info或者是warning, 只能去到第二个队列；
如果是error， 则两个队列都能去。

image.png

  1. Topics主题模式

和Routing模式很相似，区别就是不用写详细的Routing key，而可以使用通配符。（类似正则）

image.png