消息队列 MQ 1 - 3分钟让你快速了解消息队列

1 什么是消息队列

队列是一个基础的“先进先出”的数据结构，消息队列，就是一个用来存放消息的队列。
一个基本的消息队列的模型如下图，生产者负责往消息队列里写入消息，消费者通过订阅生产者发布的消息就可以消费消息。

image

2 为什么要消息队列

主要的功能有应用解藕，流量消峰，消息分发，除此之前还有保持一致性和方便动态扩容等功能。

1.应用解耦

比如电商系统，用户创建订单，会涉及到，“订单系统”，”库存系统“，“物流系统” 和 “支付系统”，如果这些是耦合的，则任何一个系统的故障都会导致订单创建失败。

可是如果使用消息队列进行应用解耦，则如下图，比如“物流系统”发生故障，则物流系统需要处理的内容被缓存在消息队列里，用户的下单操作依然可以完成，等到几分钟后物流系统恢复，这时再补充处理缓存在消息队列里的订单消息即可，终端用户是感知不到这几分钟的系统故障的。

2.流量消峰

当高并发的时候，应用系统的压力增大，此时通过消息队列把大量的请求暂存起来，然后分散到相对长的一段时间内处理，大大缓解应用系统的压力。

依然以电商系统为例，比如双11秒杀活动，假设“订单系统” 每秒能处理10000次请求，可是此时流入的是20000次请求。要处理这样的情况，要么：

• 增加服务器性能，让他能支持20000次请求，可是这种方式不够经济，因为大多数情况下10000次请求的处理能力已经绰绰有余。
• 订单超过10000次后就不允许用户下单，这个想也不太可能
• 使用消息队列，把1秒内下单订单分散成一段时间来处理。这时虽然有些用户能在下单后几十秒才能收到下单成功的状态。可是总比不能下单的体验好。

3.消息分发

数据产生方只需要把数据放到消息队列，数据消费方根据自己的需要订阅感兴趣的数据，不同数据消费方可以重复也可以不重复，互不干扰，也不需要和数据产生方关联。

如下图各个子系统将日志数据不停的写入消息队列， 数据消费方比如“日志处理1” 还可以把自己处理后的数据重新放入消息队列供其他数据消费方使用，可以避免重复计算。

使用场景，比如对于用户数据进行用户画像，精准推送等。

4.异步

A系统接收一个请求后，需要：

• 在自己本地写入数据 3ms
• 在B系统写入数据 300ms
• 在C系统写入数据 450ms
• 在D系统写入数据 200ms

则总共需要 3+300+450+200=980ms

可是如果使用MQ，A系统连续发送3条请求到MQ 5ms，则此时A系统从接受一个请求到返回响应给客户，总共 3+5=8ms， 比之前的980ms快了很多。

3 消息队列的两种模式

点对点与发布式订阅.

3.1 PTP点对点

消息从一个生产者（producer/sender）经过一个队列传给另一个消费者（consumer/receiver）。
可以有多个消费者监听一个队列，但是如果有一个消费者消费了消息，则其他消费者则获取不到消息了。所以叫做点到点模式。
发送者和接收者之间在时间上没有依赖性,队列保留着消息，可以放在内存 中也可以持久化，直到他们被消费或超时。

3.2 发布订阅 Publish/Subscribe

发布者把消息发布到一个topic，多个订阅者可以订阅同一个topic，发布的消息可以被所有的订阅者消费。所以叫做发布订阅模式。
发布者和订阅者之间有时间上的依赖性。如果发布者发布消息的时候，订阅者处于某种原因没有接收到，这个消息就丢失了。

[站外图片上传中...(image-8545bc-1594649931582)]

4 消息队列的缺点

系统可用性降低:

系统引入的外部依赖越多则越容易挂掉，以上面的电商为例子，本来订单系统，调用支付系统，库存系统，物流系统的接口就好了，现在引入MQ进入，万一MQ挂了，整套系统就奔溃了，所以降低系统可用性。

系统复杂性增加:

加入MQ后，需要考虑，如何保证一致性，如何保证消息不被重复消费，如何报纸额消息的传递顺序，如何保证消息可靠传输等等。

• 一致性问题：
  比如上面的电商系统，订单系统处理完，直接返回成功，人都以为你成功了，但是问题是，物流系统，支付系统和库存系统，只要其中一个挂了，那就会出现数据不一致的问题。
• 消息重复消费的问题：
  比如kafka里，kafka会给每条数据分配一个offset，消费者按照offset的编号顺序去消费，消费后提交offset。消费者不是一消费好一条数据就立刻去提交offset，是定期提交一次offset，如果在消费者还没提交的时候，消费者的进程重启了，那么此时已经消费过的消息的offset就没有提交，这次kafka会以为你没有消费这条数据，然后重新给你发送。导致重复消费。
• 数据丢失：
  生产者在写消息的时候，在网络传输过程就丢失了
  生产者把消息存到MQ，可是MQ自己出错了，没有保存成功
  MQ收到消息，并且暂存在内存里，可是在消费者还没来得及消费之前MQ挂了，导致暂存在内存的数据丢失
  消费者消费到这个消息，可是还没来得及处理自己就坏了，导致MQ以为他已经处理完了，不再给他发消息。

5 常见的消息队列

此外还有Amazon SQS/SNS 和 Aliyun MQTT.
下一章节会着重介绍下 Aliyun MQTT和 RocketMQ的区别和使用场景。

参考：《RocketMQ实战与原理解析》