春招面试复习：消息队列（一）- 消息队列的意义

快来打我* 2023-01-06 05:51 227阅读 0赞

MQ 主要就是用来发送和接收处理消息，但它的作用可不仅解决应用间通信问题。

# 1 MQ 的现实由来 #

在工厂我们随处可见各种传送带，很多道工序都替代了人工一次次极大耗费劳动力的往返运动，而把一套业务分成若干部分，各流程之间传输所需材料即可。用编程思想，我们可以认为是传送带的发明解决了上下游工序间的“通信”问题。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70][]

传送带的使用着实提高社会必要劳动生产时间，让人类工业社会效率显著提升。但就真的百利无一害了吗？  
我们会发现每道工序生产速度并不相同。有时上游的材料刚传送过来，工人可能正在处理上批材料，没有时间接收。不同工序的工人必须协调好什么时间往传送带上放置材料，若出现上下游工序速度不一致，上下游工人之间就得互相等待，确保不会出现传送带上的半成品材料挤压太多，无人接收！

为解决该问题，在每组工序下游配备个暂存仓库，这样上游工人就不用等下游工人有空，任何时间都可把加工完成的半成品丢到传送带，无法接收的就被暂存在仓库，下游工人可随时来取。  
配备的仓库就起到了“通信”过程中“缓存”作用。

这就是现实版的消息队列。

# 2 消息队列适用场景 #

理解了消息队列由来，看看开发中，何时需要 MQ 呢？

## 2.1 异步处理 ##

跨系统的异步通信（最早使用的有IBM MQ）或者应用内的同步变成异步（秒杀）。

比如面试常客秒杀系统，一个秒杀请求可能包含很多步骤：

*  风控
 *  锁库存
 *  生成订单
 *  通知
 *  更新统计数据

最低级的同步处理流程：App将请求发送给网关，依次调用上述流程，然后将结果返回给APP。

决定秒杀成功与否的实际上只有风控和锁库存。只要用户请求通过风控，并在Server完成库存锁定，就可给用户返回秒杀结果，对于后续生成订单、短信通知和更新统计数据等，并不一定要在秒杀请求中处理完。

所以当服务端完成前2步，确定本次请求秒杀结果，即可给用户响应，然后把请求的数据放入MQ，由MQ异步执行后续操作。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70 1][]

五步变两，不仅响应更快，且在秒杀间，可把大量服务器资源用来处理秒杀请求。秒杀结束后再把资源用于处理后面步骤，榨干了有限的服务器资源。

### 优点 ###

*  更快地返回结果
 *  减少等待，自然实现了步骤之间的并发，提升系统总体的性能，集中力量办大事(同步部分)，碎片时间做小事(异步部分)

### 缺点 ###

*  降低了数据一致性，如要保持强一致性，需要高代价的补偿(如分布式事务、对账)
 *  有数据丢失风险，如宕机重启，如要保证队列数据可用，需要额外机制保证(如双活容灾)

## 2.2 流量控制 ##

虽然使用MQ实现了相当一部分服务的异步处理，但还有个问题：如何避免过多请求压垮秒杀系统？

好程序有自我保护能力，即应该可在海量请求下，还能在自身能力范围尽可能多处理请求，拒绝处理不了的请求且保证自身运行正常，就像线程池一般顺畅。而不是像你我简单粗暴地直接拒绝请求并返回错误，这可不是啥好的用户体验。

思路就是使用MQ隔离网关和后端服务，达成流控和保护后端服务。

加入消息队列后，整个秒杀流程变为：

1.  网关收到请求后，将请求放入请求MQ
2.  后端服务从请求MQ获取APP请求，完成后续秒杀处理过程，然后返回结果  
    ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70 2][]  
    秒杀开始后，当短时内大量秒杀请求到达网关，不会直接冲击后端秒杀服务，而是先堆积在MQ，后端服务尽力从MQ消费请求并处理。

> 如果消息量特别大，消息是适合存在到redis中还是适合存到rabbitmq中？毕竟只是个小仓库，如果货量大了怎么办捏？  
> 首先redis肯定是不适合存消息的，虽然redis性能很好，但那是和主流的数据库比，一般大概能到几万tps左右；而现代的消息队列都能很轻松的做到几十万tps级别的性能。  
> 消息量特别大的时候，需要考虑使用有消息堆积能力的MQ，因为一旦消费慢，大量消息就会堆积到MQ中，这种情况不太适合用RabbitMQ，可以考虑RocketMQ、Kafka和Pulsar。

对于超时请求可直接丢弃，APP将超时无响应请求处理为秒杀失败。运维人员还可随时增加秒杀服务的实例数量来水平扩容，无需对系统其他部分更改。

### 2.2.1 优点 ###

能根据下游的处理能力自动调节流量，达到“削峰填谷”。

### 2.2.2 缺点 ###

*  增加系统调用链环节，导致总体响应延时加长
 *  上下游系统都要将同步调用改为异步消息，增加系统复杂度

有无简单点流控方式？如果能预估秒杀服务的能力，就可用MQ实现个令牌桶，更简单流控。

### 2.2.3 令牌桶控流原理 ###

单位时间内只发放固定数量的令牌到令牌桶，规定服务在处理请求前须先从令牌桶中拿个令牌，若令牌桶中无令牌，则拒绝请求。  
这保证单位时间，能处理请求不超过发放令牌数量，达成流控。  
实现也简单，无需破坏原有调用链，只要网关在处理APP请求时加个获取令牌流程。  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70 3][]

令牌桶可简单地用一个有固定容量的消息队列加一个“令牌发生器”来实现：令牌发生器按照预估的处理能力，匀速生产令牌并放入令牌队列（如果队列满了则丢弃令牌），网关在收到请求时去令牌队列消费一个令牌，获取到令牌则继续调用后端秒杀服务，如果获取不到令牌则直接返回秒杀失败。

> 令牌桶可以用消息队列实现，也可以用Redis实现，也可以写一个简单的令牌桶服务，原理是一样的。

以上常用的使用消息队列两种进行流量控制的设计方法，可以根据各自的优缺点和不同的适用场景进行合理选择。

## 2.3 服务解耦 ##

比如新订单创建时：

1.  支付系统需要发起支付流程
2.  风控系统需要审核订单的合法性
3.  客服系统需要给用户发短信告知用户
4.  经营分析系统需要更新统计数据；  
    …

这些订单下游系统都需实时获得订单数据。随业务发展，订单下游不断变化，每个系统可能只需订单数据子集，订单服务团队不得不花精力，应对不断增变下游，不停修改订单系统与下游系统之间接口。任一下游系统接口变更，都需订单模块重上线，对核心的订单服务，这是不可接受的。

所有的电商都选择用MQ解决类似的系统高耦合问题。  
订单服务在订单变化时发送一条消息到MQ的一个主题Order，所有下游系统都订阅该主题，这样每个下游系统都可获得一份实时完整订单数据。

无论增加、减少下游系统或是下游系统需求如何变化，订单服务无需更改，实现了订单服务与下游服务解耦。

### 优点 ###

*  可在模块、服务、接口等不同粒度上实现解耦
 *  订阅/消费模式也可在数据粒度上解耦

## 基于 Pub/Sub 发布/订阅模型实现的事件驱动 ##

原来使用 ETL、HTTP 调用 API方式，现在使用 MQ 可定时任务去拉取数据。  
再比如实现一个微服务系统间的观察者模式。

## 实现事务的最终一致性 ##

比如使用 rabbitmq 和 rocketmq。

其他适用场景还有比如连接流计算任务和数据、将消息广播给大量接收者。

在单体应用里需要用队列解决的，在分布式系统中大都可用MQ解决。  
MQ适用场景还是很多的，如秒杀、发邮件、发短信、高并发订单等。  
注意

## 不适合 MQ 的场景 ##

如银行转账、电信开户、第三方支付等。  
关键还是要意识到消息队列的优劣点，然后分析场景是否适用。

# 3 是否可利用共享内存、RDMA提高MQ性能？ #

如果你说的共享内存指的是PageCache，很多消息队列都会用到，RDMA据我所知常见的几种消息队列应该都还没有使用，像Kafka它在消费的时候，直接使用Zero Copy，数据直接从PageCache写到NIC的缓冲区中，都不需要进入应用内存空间。

另外，现代的消息队列瓶颈并不在本机内存数据交换这块，主要还是受限于网卡带宽或者磁盘的IO，像JMQ、Kafka这些消息队列，都可以打满万兆网卡或者把磁盘的读写速度拉满。

# 4 APP⇆网关–生产–>消息队列–消费–>秒杀服务问题 #

## 4.1 海量请求都放在MQ，MQ整体容量如何衡量？ ##

消息队列不可能能存放无限的消息，消息队列满应该也会有拒绝策略，比如线程池的任务队列，任务队列满，并且超过最大的线程池数，四种的拒绝策略。

实际上，只要有足够的磁盘容量，消息队列确实可以存放无限的消息。像秒杀请求这种数据，峰值并发高，但总数据量并不是很大，所以，堆积在消息队列中完全没问题。

## 4.2 APP响应超时，即网关超过一定的时间没有返回 ##

消息还在任务队列中，还是会被秒杀服务处理，这样的话，返回给APP秒杀失败，但是秒杀服务已经消费了消息？难道是在网关做补偿么？如果连接已经断开，将秒杀服务对此消息的处理做回滚操作么？

都按照秒杀失败处理即可。

## 4.3 网关和秒杀服务是通过消息队列进行通信，那响应消息也通过队列进行返回么？ ##

队列中会有APP对应的地址比如IP之类的？那这样的话，APP的海量连接都同时连接着网关，不是会有问题么？  
响应一般采用RPC来实现。超时或者返回秒杀结果之前，网关和APP确实要保持连接，这是HTTP协议决定的。至于网关能不能承受海量的APP连接，这个应该不用担心，网关的作用就是用来抗海量连接的，它也会有各种方法来解决这个问题。

## 4.4 消息队列应该也会做多备的策略？比如队列消息的服务挂了，那些消息全部不见，这样不是也会存在问题么？ ##

是的，大部分生产系统中的消息队列要配置成集群，确保可用性和数据可靠性，这个后面的课程我们会讲。

*  参考  
    《消息队列高手课》

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70]: /images/20221119/262dcab30f064dd4b13f0e3e3190a93c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70 1]: /images/20221119/f316347e96b34019a7c8a0615a4a84e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70 2]: /images/20221119/861d4909c009448ea0cdf47960cc10f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw_size_1_color_FFFFFF_t_70 3]: /images/20221119/9412b3037e8f4231b60c403cc9ba0cbd.png