消息队列基本概念

什么是消息队列

异步通讯的中间件 : 存放消息的容器。当我们需要使用消息时，取出消息供我们使用。

消息是一种数据结构（当然，对象也可以看做是一种特殊的消息），它包含消费者与生产者双方都能识别的数据，这些数据需要在不同的进程（机器）之间进行传递，并可能会被多个完全不同的客户端消费。

生产者先将消息投递一个叫做「队列」的容器中，然后再从这个容器中取出消息，最后再转发给消费者，仅此而已。本质：一发一存一消费，可以视为一种转发器。

消息队列的功能

分布式场景下，通过消息传递和消息排队模型，提供系统解耦、异步通信和流量削峰的功能。

场景举例：电商业务中最常见的「订单支付」场景：在订单支付成功后，需要更新订单状态、更新用户积分、通知商家有新订单、更新推荐系统中的用户画像等等。

缺点：系统彼此依赖，耦合性比较高，消息只能同步逐层传递，如果订单比较多，系统的吞吐量就可能不足。

此时引入消息队列：

引入 MQ 后，订单支付只需要关注它最重要的流程：更新订单状态即可。其他不重要的事情全部交给 MQ 来通知。这便是 MQ 解决的最核心的问题：系统解耦。

改造前订单系统依赖 3 个外部系统，改造后仅仅依赖 MQ，而且后续业务再扩展（比如：营销系统打算针对支付用户奖励优惠券），也不涉及订单系统的修改，从而保证了核心流程的稳定性，降低了维护成本。

这个改造还带来了另外一个好处：因为 MQ 的引入，更新用户积分、通知商家、更新用户画像这些步骤全部变成了异步执行，能减少订单支付的整体耗时，提升订单系统的吞吐量。这便是 MQ 的另一个典型应用场景：异步通信。

除此以外，由于队列能转储消息，对于超出系统承载能力的场景，可以用 MQ 作为 “漏斗” 进行限流保护，即所谓的流量削峰。

消息队列与RPC

从MQ 的通信模型来看，可以理解成：两次 RPC + 消息转储。

1、引入 MQ 后，由之前的一次 RPC 变成了现在的两次 RPC，而且生产者只跟队列耦合，它根本无需知道消费者的存在。
2、多了一个中间节点「队列」进行消息转储，相当于将同步变成了异步。

常见类型

点对点模型

也叫消息队列模型。如果拿上面那个“民间版”的定义来说，那么系统A发送的消息只能被系统B接收，其他任何系统都不能读取A发送的消息。日常生活的例子比如电话客服就属于这种模型：同一个客户呼入电话只能被一位客服人员处理，第二个客服人员不能为该客户服务。

发布/订阅模型

主题（Topic） 发布者（Publisher）订阅者（Subscriber）。

和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布/订阅模型。

消息队列设计

（待定，积累更多实际经验补充）

功能性需求：发消息、存消息、消费消息

非功能性需求：高性能、高可用、高扩展