一、使用消息队列的场景

1. 异步处理。
2. 流量控制。
3. 服务解耦。
4. 发布订阅。
5. 高并发缓冲。

1.1、消息队列的异步处理

主要应用于短信通知、终端状态推送、App推送、用户注册等。

同步处理：

异步处理：

异步处理的优势：更快速返回结果；减少等待，实现并发处理，提升系统总体性能。

消息队列的模式可以有：
（1）1对1：读取之后立刻从队列中移除消息。
（2）1对多：这种模型是发布订阅模型，消息队列的元素可以被重复消费。至于何时删除消息，可以设置消息的存活周期；比如kafka可以设置24H后删除消息。

1.2、消息队列的流量控制（削峰）

在秒杀场景下的下单状态，使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。

设置消息队列的最大限制数量，在达到最大数量时网关不再生成消息到消息队列中。

可以这么想：有一个商品秒杀活动，商品数量为100，当消息队列的数量达到100时不再生产秒杀成功消息，直接返回秒杀失败给用户，只有1到100的用户秒杀成功 获得商品。

1.3、消息队列的服务解耦

A系统负责数据分发，其他系统调用A系统提供的接口处理数据；当新增一个系统时，A系统需要改代码调用新的系统，并实现新的接口给新的系统去调用。这种方式是系统间高度耦合。

使用消息队列，A系统负责将数据分发到MQ，消费端根据需要从MQ获取消息即可，不需要就取消MQ的消费。

1.4、消息队列的发布订阅

用户需要先去注册，才能收到相关消息。

比如游戏里面跨服：
（1） 广播今天整体还剩多少把屠龙刀可以暴。
（2） 广播用户暴的屠龙刀的消息。

1.5、消息队列的高并发缓冲

这个和消息队列的流量控制（削峰）有些类似。区别在于，这里没有大小限流，可能在某个时间点会出现超过后端处理能力的访问；比如后端处理能力是50000每秒，在某个时间点出现每秒80000的访问，这就可能造成击穿。

针对此情况，消息全部放入消息队列，消息队列提供可以把数据固化到磁盘的能力，降低高峰数据对后端的短暂冲击。

比如，后端处理能力50000，某个短暂时间点（比如一秒的时间）数据访问达到80000，消息队列将多的数据缓存到磁盘，后端仍然处理50000数据；冲击点退去后，访问数据降到了30000，那么消息队列将把缓存的数据放到后端处理。

比如kafka 日志服务、监控上报。

二、消息队列的基本概念和原理

消息队列全称MessageQueue，简称MQ。本质是一个队列，FIFO先进先出，只不过队列中存放的内容是message，从而称为消息队列（消息+队列）。

主要用途：不同服务server、进程process、线程thread之间通信。

2.1、消息的生产者和消费者

消息生产者Producer：发送消息到消息队列。
消息消费者Consumer：从消息队列接收消息。
被动接受消息 s->c。
主动拉取消息 s<- c pull。

通常，是由消费者Consumer去拉取消息，避免采用推送的方式。因为服务端不知道消费者的处理能力，可能会造成数据丢失。

2.2、Broker

Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。一般来说，一个服务器机器只有一个Broker，不要出现多个Broker。

如果有多个Broker，可以采用集群的方式。

2.3、点对点消息队列模型 ----- 线程池

消息生产者向一个特定的队列发送消息，消息消费者从该队列中接收消息。
一条消息只有一个消费者能收到。

2.4、发布订阅消息模型

实际操作过程中，发布订阅消息模型中，支持向一个特定的主题Topic发布消息，0个或多个订阅者接收来自这个消息主题的消息。在这种模型下，发布者和订阅者彼此不知道对方。

2.5、消息的顺序性保证

基于Queue消息模型，利用FIFO先进先出的特性，可以保证消息的顺序性。

2.6、消息的ACK确认机制

即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。
如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。

通过牺牲吞吐量获得实时性。

2.7、消息的持久化

消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。

对于生产者，将数据发送到消息队列，消息队列会保存多个副本，即使MQ服务器奔溃，重启仍能找到生产者的消息数据。
对于消费者，拉取到消息后，将返回一个信息给MQ告诉它已经获得了消息，MQ将保存相关数据，即使MQ服务器奔溃，重启仍能知道消费者已经获取了哪些数据，避免重复发送。

2.8、消息的同步和异步收发

同步： 消息的收发支持同步收发的方式 一应一答。
同时还有另一种同步方式：同步收发场景下，消息生产者和消费者双向应答模式。
消息的接收如果以同步的方式(Pull)进行接收，如果队列中为空，此时接收将处于同步阻塞状态，会一直等待，直到消息的到达。

异步： 消息的收发同样支持异步方式：异步发送消息，不需要等待消息队列的接收确认；异步接收消息，以Push的方式触发消息消费者接收消息。

2.9、消费组的概念

类似线程池；如果消费者的处理能力较低时，可以使用消费组来处理，一个消费组里面包含多个消费者。

比如，MQ推送数据的能力是10w每秒，而消费者的处理能力是1w每秒，那么就可以使用一个消费组包含10个消费者来处理消息。这时消费者使用的是点对点消息队列模型 。

三、消息队列产品

特性	RabbitMQ	RocketMQ	Kafka	ZeroMQ
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景	100万级别，最早设计用于股票实时交易系统
topic 数量对吞吐量的影响		topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	微秒级，这是RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内	延迟在微妙级别/毫秒级
可用性	高，基于主从架构实现高可用	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用	不是一个独立的服务，要嵌套到自己的程序里面去
消息可靠性	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，支持分布式部署，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用	如果需求是将消息队列的功能集成到系统进程中，可以考虑使用

后言

本专栏知识点是通过<零声教育>的系统学习，进行梳理总结写下文章，对c/c++linux系统提升感兴趣的读者，可以点击链接,详细查看详细的服务:C/C++服务器课程