|
|
51CTO旗下网站
|
|
移动端

扪心自问,你真的熟练掌握MQ了吗?

大家平时也有用到一些消息中间件(MQ),但是对其理解可能仅停留在会使用 API 能实现生产消息、消费消息就完事了。

作者:jianfeng来源:石杉的架构笔记|2019-07-11 10:45

【大咖·来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

大家平时也有用到一些消息中间件(MQ),但是对其理解可能仅停留在会使用 API 能实现生产消息、消费消息就完事了。

图片来自pexels

对 MQ 更加深入的问题,可能很多人没怎么思考过。比如,你跳槽面试时,如果面试官看到你简历上写了熟练掌握消息中间件。

那么很可能给你发起如下 4 个面试连环炮:

  • 为什么要使用 MQ?
  • 使用了 MQ 之后有什么优缺点?
  • 怎么保证 MQ 消息不丢失?
  • 怎么保证 MQ 的高可用性?

本文将通过一些场景,配合着通俗易懂的语言和多张手绘彩图,讨论一下这些问题。

为什么要使用 MQ?

相信大家也听过这样的一句话:好的架构不是设计出来的,是演进出来的。

这句话在引入 MQ 的场景同样适用,使用 MQ 必定有其道理,是用来解决实际问题的。而不是看见别人用了,我也用着玩儿一下。

其实使用 MQ 的场景挺多的,但是比较核心的有 3 个:

  • 异步
  • 解耦
  • 削峰填谷

异步

我们通过实际案例说明:假设 A 系统接收一个请求,需要在自己本地写库执行 SQL,然后需要调用 BCD 三个系统的接口。

假设自己本地写库要 3ms,调用 BCD 三个系统分别要 300ms、450ms、200ms。

那么最终请求总延时是 3+300+450+200=953ms,接近 1s,可能用户会感觉太慢了。

此时整个系统大概是这样的:

但是一旦使用了 MQ 之后,系统 A 只需要发送 3 条消息到 MQ 中的 3 个消息队列,然后就返回给用户了。

假设发送消息到 MQ 中耗时 20ms,那么用户感知到这个接口的耗时仅仅是 20+3=23ms,用户几乎无感知,倍儿爽!

此时整个系统结构大概是这样的:

可以看到,通过 MQ 的异步功能,可以大大提高接口的性能。

解耦

假设 A 系统在用户发生某个操作的时候,需要把用户提交的数据同时推送到 B、C 两个系统的时候。

这个时候负责 A 系统的哥们想:没事啊,B、C 两个系统给我提供一个 HTTP 接口或者 RPC 接口,我把数据推送过去不就完事了嘛。负责 A 系统的哥们美滋滋。

如下图所示:

一切看起来很美好,但是随着业务快速迭代,这个时候系统 D 也想要这个数据。那既然这样,A 系统的开发同学就改咯,在发送数据给 BC 的同时加上一个 D。

但是,越到后面越发现,麻烦来了。整个系统好像不止这个数据要发送给 BCD、还有第二、第三个数据要发送给 BCD。甚至有时候又加入了 E、F 等系统,他们也要这个数据。

并且有时候可能 B 系统突然又不要这个数据了,A 系统改来改去,A 系统的开发哥们头皮发麻。

更复杂的场景是,数据通过接口传给其他系统有时候还要考虑重试、超时等一些异常情况,真是头发都白了呀。

来看下图,体会一下这无助的现场:

这个时候,就该我们的 MQ 粉墨登场了!这种情况下使用 MQ 来解耦是再合适不过了,因为负责 A 系统的哥们只需要把消息扔到 MQ 就行了,其他系统按需来订阅消息就好了。

就算某个系统不需要这个数据了,也不会需要 A 系统改动代码。看看加入 MQ 解耦的下图,是不是清爽了很多:

削峰填谷

举个例子,比如我们的订单系统,在下单的时候就会往数据库写数据。但是数据库只能支撑每秒 1000 左右的并发写入,并发量再高就容易宕机。

低峰期的时候并发也就 100 多个,但是在高峰期时候,并发量会突然激增到 5000 以上,这个时候数据库肯定死了。

如下图,来感受一下数据库被打死的绝望:

但是使用了 MQ 之后,情况就变了!消息被 MQ 保存起来了,然后系统就可以按照自己的消费能力来消费,比如每秒 1000 个数据,这样慢慢写入数据库,这样就不会打死数据库了。

整个过程,如下图所示:

至于为什么叫做削峰填谷呢?来看看这个图:

如果没有用 MQ 的情况下,并发量高峰期的时候是有一个“顶峰”的,然后高峰期过后又是一个低并发的“谷”。

但是使用了 MQ 之后,限制消费消息的速度为 1000QPS,但是这样一来,高峰期产生的数据势必会被积压在 MQ 中,高峰就被“削”掉了。

但是因为消息积压,在高峰期过后的一段时间内,消费消息的速度还是会维持在 1000QPS,直到消费完积压的消息,这就叫做“填谷”。

通过上面的分析,大家就可以知道为什么要使用 MQ,以及使用了 MQ 有什么好处。知其所以然,明白了自己的系统为什么要使用 MQ。

这样以后别人问你为啥要用 MQ,就不会出现 “我们组长要用 MQ 我们就用了” 这样尴尬的回答了。

使用了 MQ 之后有什么优缺点?

看到这个问题蒙圈了,用了就用了嘛!优点上面已经说了,但是这个缺点是啥啊。好像没啥缺点啊。

如果你这样想,就大错特错了,在设计系统的过程中,除了要清楚的知道为什么要用这个东西,还要思考一下用了之后有什么坏处。这样才能心里有底,防范于未然。

接下来我们就讨论一下,用 MQ 会有什么缺点吧?

系统可用性降低

大家想象一下,上面的说解耦的场景,本来 A 系统的哥们要把系统关键数据发送给 BC 系统的,现在突然加入了一个 MQ 了,现在 BC 系统接收数据要通过 MQ 来接收。

但是大家有没有考虑过一个问题,万一 MQ 挂了怎么办?这就引出一个问题,加入了 MQ 之后,系统的可用性是不是就降低了?

因为多了一个风险因素:MQ 可能会挂掉。只要 MQ 挂了,数据没了,系统运行就不对了。

系统复杂度提高

本来我的系统通过接口调用一下就能完事的,但是加入一个 MQ 之后,需要考虑消息重复消费、消息丢失、甚至消息顺序性的问题。

为了解决这些问题,又需要引入很多复杂的机制,这样一来是不是系统的复杂度提高了。

数据一致性问题

本来好好的,A 系统调用 BC 系统接口,如果 BC 系统出错了,会抛出异常,返回给 A 系统让 A 系统知道,这样的话就可以做回滚操作了。

但是使用了 MQ 之后,A 系统发送完消息就完事了,认为成功了。而刚好 C 系统写数据库的时候失败了,但是 A 认为 C 已经成功了?这样一来数据就不一致了。

通过分析引入 MQ 的优缺点之后,就明白了使用 MQ 有很多优点,但是会发现它带来的缺点又会需要你做各种额外的系统设计来弥补。

***你可能会发现整个系统复杂了好几倍,所以设计系统的时候要基于这些考虑做出取舍,很多时候你会发现该用的还是要用的。

怎么保证 MQ 消息不丢失?

使用了 MQ 之后,还要关心消息丢失的问题。这里我们挑 RabbitMQ 来说明一下吧。

生产者弄丢了数据

RabbitMQ 生产者将数据发送到 RabbitMQ 的时候,可能数据在网络传输中搞丢了,这个时候 RabbitMQ 收不到消息,消息就丢了。

RabbitMQ 提供了两种方式来解决这个问题:

事务方式:在生产者发送消息之前,通过`channel.txSelect`开启一个事务,接着发送消息。

如果消息没有成功被 RabbitMQ 接收到,生产者会收到异常,此时就可以进行事务回滚`channel.txRollback`,然后重新发送。假如 RabbitMQ 收到了这个消息,就可以提交事务`channel.txCommit`。

但是这样一来,生产者的吞吐量和性能都会降低很多,现在一般不这么干。

另外一种方式就是通过 Confirm 机制:这个 Confirm 模式是在生产者那里设置的,就是每次写消息的时候会分配一个唯一的 ID,然后 RabbitMQ 收到之后会回传一个 ACK,告诉生产者这个消息 OK 了。

如果 RabbitMQ 没有处理到这个消息,那么就回调一个 Nack 的接口,这个时候生产者就可以重发。

事务机制和 Confirm 机制***的不同在于事务机制是同步的,提交一个事务之后会阻塞在那儿。

但是 Confirm 机制是异步的,发送一个消息之后就可以发送下一个消息,然后那个消息 RabbitMQ 接收了之后会异步回调你一个接口通知你这个消息接收到了。

所以一般在生产者这块避免数据丢失,都是用 Confirm 机制的。

RabbitMQ 弄丢了数据

RabbitMQ 集群也会弄丢消息,这个问题在官方文档的教程中也提到过,就是说在消息发送到 RabbitMQ 之后,默认是没有落地磁盘的,万一 RabbitMQ 宕机了,这个时候消息就丢失了。

所以为了解决这个问题,RabbitMQ 提供了一个持久化的机制,消息写入之后会持久化到磁盘。

这样哪怕是宕机了,恢复之后也会自动恢复之前存储的数据,这样的机制可以确保消息不会丢失。

设置持久化有两个步骤:

  • ***个是创建 Queue 的时候将其设置为持久化的,这样就可以保证 RabbitMQ 持久化 Queue 的元数据,但是不会持久化 Queue 里的数据。
  • 第二个是发送消息的时候将消息的 deliveryMode 设置为 2,就是将消息设置为持久化的,此时 RabbitMQ 就会将消息持久化到磁盘上去。

但是这样一来可能会有人说:万一消息发送到 RabbitMQ 之后,还没来得及持久化到磁盘就挂掉了,数据也丢失了,怎么办?

对于这个问题,其实是配合上面的 Confirm 机制一起来保证的,就是在消息持久化到磁盘之后才会给生产者发送 ACK 消息。

万一真的遇到了那种极端的情况,生产者是可以感知到的,此时生产者可以通过重试发送消息给别的 RabbitMQ 节点。

消费端弄丢了数据

RabbitMQ 消费端弄丢了数据的情况是这样的:在消费消息的时候,刚拿到消息,结果进程挂了,这个时候 RabbitMQ 就会认为你已经消费成功了,这条数据就丢了。

对于这个问题,要先说明一下 RabbitMQ 消费消息的机制:在消费者收到消息的时候,会发送一个 ACK 给 RabbitMQ,告诉 RabbitMQ 这条消息被消费到了,这样 RabbitMQ 就会把消息删除。

但是默认情况下这个发送 ACK 的操作是自动提交的,也就是说消费者一收到这个消息就会自动返回 ACK 给 RabbitMQ,所以会出现丢消息的问题。

所以针对这个问题的解决方案就是:关闭 RabbitMQ 消费者的自动提交 ACK,在消费者处理完这条消息之后再手动提交 ACK。

这样即使遇到了上面的情况,RabbitMQ 也不会把这条消息删除,会在你程序重启之后,重新下发这条消息过来。

怎么保证 MQ 的高可用性?

使用了 MQ 之后,我们肯定是希望 MQ 有高可用特性,因为不可能接受机器宕机了,就无法收发消息的情况。

这一块我们也是基于 RabbitMQ 这种经典的 MQ 来说明一下:RabbitMQ 是比较有代表性的,因为是基于主从做高可用性的,我们就以他为例子讲解***种 MQ 的高可用性怎么实现。

RabbitMQ 有三种模式:

  • 单机模式
  • 普通集群模式
  • 镜像集群模式

单机模式

单机模式就是 Demo 级别的,就是说只有一台机器部署了一个 RabbitMQ 程序。

这个会存在单点问题,宕机就玩完了,没什么高可用性可言。一般就是你本地启动了玩玩儿的,没人生产用单机模式。

普通集群模式

这个模式的意思就是在多台机器上启动多个 RabbitMQ 实例。类似的 Master-Slave 模式一样。

但是创建的 Queue,只会放在一个 Master RabbtiMQ 实例上,其他实例都同步那个接收消息的 RabbitMQ 元数据。

在消费消息的时候,如果你连接到的 RabbitMQ 实例不是存放 Queue 数据的实例,这个时候 RabbitMQ 就会从存放 Queue 数据的实例上拉取数据,然后返回给客户端。

总的来说,这种方式有点麻烦,没有做到真正的分布式,每次消费者连接一个实例后拉取数据。

如果连接到不是存放 Queue 数据的实例,这个时候会造成额外的性能开销。如果从放 Queue 的实例拉取,会导致单实例性能瓶颈。

如果放 Queue 的实例宕机了,会导致其他实例无法拉取数据,这个集群都无法消费消息了,没有做到真正的高可用。

所以这个事儿就比较尴尬了,这就没有什么所谓的高可用性可言了,这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个 Queue 的读写操作。

镜像集群模式

镜像集群模式才是真正的 RabbitMQ 的高可用模式,跟普通集群模式不一样的是:创建的 Queue 无论元数据还是 Queue 里的消息都会存在于多个实例上。

每次写消息到 Queue 的时候,都会自动把消息到多个实例的 Queue 里进行消息同步。

这样的话任何一个机器宕机了,别的实例都可以用来提供服务,这样就做到了真正的高可用了。

但是也存在着不好之处:

  • 性能开销过高,消息需要同步所有机器,会导致网络带宽压力和消耗很重。
  • 扩展性低:无法解决某个 Queue 数据量特别大的情况,导致 Queue 无法线性拓展。就算加了机器,那个机器也会包含 Queue 的所有数据,Queue 的数据没有做到分布式存储。

对于 RabbitMQ 的高可用一般的做法都是开启镜像集群模式,这样起码来说做到了高可用,一个节点宕机了,其他节点可以继续提供服务。

总结

通过本篇文章,分析了对于 MQ 的一些常规问题:

  • 为什么使用 MQ?
  • 使用 MQ 有什么优缺点?
  • 如何保证消息不丢失?
  • 如何保证 MQ 高可用性?

但是,这些问题仅仅是使用 MQ 的其中一部分需要考虑的问题,事实上,还有其他更加复杂的问题需要我们去解决。

比如:如何保证消息的顺序性?消息队列如何选型?消息积压问题如何解决?

本文仅仅是针对 RabbitMQ 的场景举例子。还有其他比较的消息队列,比如 RocketMQ、Kafka。

不同的 MQ 在面临上述问题的时候,要根据他们的原理机制来做对应的处理,这些都是本文没有顾及的内容,将在后面的文章中讨论。

【编辑推荐】

  1. APICloud发布低代码开发平台 效率工具***IT人效革命
  2. Java消息队列总结篇(ActiveMQ、RabbitMQ、ZeroMQ、Kafka)
  3. Python+SQL无敌组合,值得你Pick
  4. 不改代码也能全面Serverless化,阿里中间件如何破解这一难题?
  5. 90%的Java程序员,都扛不住这波消息中间件的面试四连炮!
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

115人订阅学习

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

371人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

758人订阅学习

读 书 +更多

The Ruby Way(第二版)中文版

本书采用“如何解决问题”的方式阐述Ruby编程,涵盖了以下内容:Ruby术语和基本原理;数字、字符串等低级数据类型的操作;正则表达式;国际...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微