消 息 队 列

1 消息队列的用途

1.1 解耦

通过消息队列，降低系统间的耦合，避免过多的调用。

• 就好像公司的行政小姐姐要通知一件事情，她通常会是在群里发一个公告，然后我们扣1就行了。要是一个个通知，她要通知几十上百次。

1.2 异步

比如在完成一个订单支付的任务后，我们要扣减库存、增加积分、发送消息等等，这样一来这个链路就长了，链路一长，响应时间就变长了。引入消息队列，除了更新订单状态，其它的都可以异步去做，这样一来就来，就能更快地响应我们的上游。

为什么不用多线程之类的方式做异步呢？

• 只用多线程做异步，不是还得写代码去调那一堆下游吗，所以这又回到了解耦这个问题上。

1.3 流量削峰

消息队列同样可以用来削峰。

• 用一个比喻，一条河流，假如它的下游能容纳的水量是有限的，为了防止洪水冲垮堤坝，我们应该怎么办呢？

• 我们可以在上游修建一个水库，洪峰来的时候，我们先把水给蓄起来，闸口里只放出下游能承受地住的水量。

• 放在我们的系统，也是一个道理。比如秒杀系统，平时流量很低，但是要做秒杀活动，秒杀的时候流量疯狂怼进来，你的服务器，Redis，MySQL各自的承受能力都不一样，直接全部流量照单全收肯定有问题啊，严重点可能直接打挂了。

• 所以一样，我们可以把请求放到队列里面，只放出我们下游服务能处理的流量，这样就能抗住短时间的大流量了。

1.4 延时任务

除了这三大用途之外，还可以利用队列本身的顺序性，来满足消息必须按顺序投递的场景；利用队列 + 定时任务来实现消息的延时消费

2 消息队列的本质

消息队列核心：发、存、消费。

生产者先将消息发一个叫做「队列」的容器中，存储在里面。然后再从这个容器中取出消息，最后再转发给消费者进行消费。

上面这个图便是消息队列最原始的模型，它包含了消息队列中的一两个关键词消息和队列：

1. 消息：就是要传输的数据，可以是最简单的文本字符串，也可以是自定义的复杂格式。

2. 队列：大家应该再熟悉不过了，是一种先进先出数据结构。它是存放消息的容器，消息从队尾入队，从队头出队，入队即发消息的过程，出队即收消息的过程。

所以消息队列的本质就是把要传输的数据放在队列中。

围绕着这个本质：

• 把数据放到消息队列的角色就是生产者
• 把数据从队列中取出的就是消费者

3 消息队列模型

在上面已经了解了消息队列模型的本质，随着应用场景的变化，消息队列的模型逐渐发生了一些演进。

就好像我们的文字通讯，最开始单对单地发消息，后来可以群发，再后来，可以拉一个群聊。

3.1 队列模型

最初的消息队列就是上面的原始模型，它是一个严格意义上的队列（Queue）。消息按照什么顺序写进去，就按照什么顺序读出来。不过，队列没有 “读” 这个操作，读就是出队，从队头中 “删除” 这个消息。

如果有多个生产者往同一个队列里面发送消息，这个队列中可以消费到的消息，就是这些生产者生产的所有消息的合集。消息的顺序就是这些生产者发送消息的自然顺序。

如果有多个消费者接收同一个队列的消息，这些消费者之间实际上是竞争的关系，每个消费者只能收到队列中的一部分消息，也就是说任何一条消息只能被其中的一个消费者收到

3.2 发布 - 订阅模型

如果需要将一份消息数据分发给多个消费者，并且每个消费者都要求收到全量的消息。很显然，队列模型无法满足这个需求。

• 一个可行的方案是：为每个消费者创建一个单独的队列，让生产者发送多份。这种做法比较笨，而且同一份数据会被复制多份，也很浪费空间。

为了解决这个问题，就演化出了另外一种消息模型：发布-订阅模型。

在发布 - 订阅模型中，消息的发送方称为发布者（Publisher），消息的接收方称为订阅者（Subscriber），服务端存放消息的容器称为主题（Topic）`。发布者将消息发送到主题中，订阅者在接收消息之前需要先“订阅主题”。“订阅”在这里既是一个动作，同时还可以认为是主题在消费时的一个逻辑副本，每份订阅中，订阅者都可以接收到主题的所有消息。

仔细对比下它和 “队列模式” 的异同：生产者就是发布者，队列就是主题，消费者就是订阅者，无本质区别。唯一的不同点在于：一份消息数据是否可以被多次消费。

4 消息队列代价

天下没有白吃的午餐——这句话放在系统设计中同样适用。引入了消息队列，解决了一些问题，但同时也增加了系统的复杂性和维护成本。

4.1 高可用

我们引入了消息队列，虽然降低了系统间的耦合，但是，我们对消息队列的依赖也变重了，想想，要是消息队列挂了，那我们下游就全凉了。

所以，我们消息队列的部署必须保证高可用，至少是主/从，一般都得集群/分布式。

4.2 消息丢失问题（后续记得补充：标记）

我们将数据写到消息队列上，下游服务没来得及取消息队列的数据，突然挂了。如果没有做任何的措施，我们的数据就丢了。

那可怎么办呢？

消息队列中的数据得想办法存在别的地方，这样才尽可能减少数据的丢失。

问题又来了，存在哪呢？

• 磁盘？
• 数据库？
• Redis？
• 分布式文件系统？

同步存储还是异步存储？

4.3 重复消费问题（后续记得补充：标记）

要是我们网络延迟或者什么原因，导致下游重复消费怎么办？

我们这个问题是在消息队列解决？还是在下游服务解决？

还有其它的顺序消息等等问题。

这些问题都是选型时候需要充分考虑的。

5 消息队列选择

目前在市面上比较主流的主要有四大消息中间件：Kafka、ActiveMQ、RabbitMQ、RocketMQ 。

参考：https://mp.weixin.qq.com/s/KhTKi94TiY4Q2yzXQ9LXCw