见名知义,消息队列主要就是用来发送和接收处理消息,但它的作用可不仅解决应用间通信问题。

<>1 消息队列的现实由来

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

传送带的使用着实提高社会必要劳动生产时间,让人类工业社会效率显著提升。但就真的百利无一害了吗?

我们会发现每道工序生产速度并不相同。有时上游的材料刚传送过来,工人可能正在处理上批材料,没有时间接收。不同工序的工人必须协调好什么时间往传送带上放置材料,若出现上下游工序速度不一致,上下游工人之间就得互相等待,确保不会出现传送带上的半成品材料挤压太多,无人接收!

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

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

<>2 消息队列适用场景

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

<>2.1 异步处理

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

* 风控
* 锁库存
* 生成订单
* 通知
* 更新统计数据
毫无优化的处理流程是:App将请求发送给网关,依次调用上述流程,然后将结果返回给APP。

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

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

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

<>优点

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

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

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

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

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

加入消息队列后,整个秒杀流程变为:

* 网关收到请求后,将请求放入请求MQ
* 后端服务从请求MQ获取APP请求,完成后续秒杀处理过程,然后返回结果

秒杀开始后,当短时内大量秒杀请求到达网关,不会直接冲击后端秒杀服务,而是先堆积在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请求时加个获取令牌流程。

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

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

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

<>2.3 服务解耦

比如新订单创建时:

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


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

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

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

<>优点

* 可在模块、服务、接口等不同粒度上实现解耦
* 订阅/消费模式也可在数据粒度上解耦
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 消息队列应该也会做多备的策略?比如队列消息的服务挂了,那些消息全部不见,这样不是也会存在问题么?

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

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

技术
©2020 ioDraw All rights reserved
实现LRU Cache(java版)一个学生关于鸿蒙系统的一些看法Keras输出模型的各层的结果python中list和str互相转换flutter学习--搜索框抖音比较火的 黑客帝国-代码雨(免费送)浙大数据结构期中考试试题python计算macd的方法k8s删除pod使用函数实现两个数的交换(C语言)