我们真的需要使用 MQ 吗?MQ 使用场景分享

Updated on with 0 views and 0 comments

Hello,大家好,最近两周一直在加班,9106 的节奏的,真的是累成狗了。不过最近项目进入提测,就稍微闲了一点。

上周的时候,看了一场架构师之路沈剑老师的一场直播,最近又重温了一下,根据自己的认知总结了一下,分享给大家。

MQ 想必大家或多或少都用过,接入 MQ 之后的整体架构如下:

可以看到使用 MQ 之后,上下游通信就变成图上的这种方式。

这种跨进程的通信方式,我们还有一种常用的解决方案,使用 Dubbo 等这类 RPC 服务。

理论上使用 RPC 的跨进程通信的场景,使用 MQ 也能解决,当然反过来也能说通。

那为什么不都用 RPC,或者 MQ 来解决那

这其实都是业务场景决定的,抛开业务场景来谈架构都是耍流氓!没有全能的架构,只要适合的架构。

下面我们来看看那些场景适合 RPC,而那些场景适合 MQ。

RPC 场景

使用 RPC 的场景一般都是上有服务需要实时依赖下游服务的返回。

我们以一个登录服务为例,架构图如下:

用户发起的登录请求首先由对外的 WEB 服务接受,然后 WEB 服务服务调用用户服务查询用户信息,然后比对用户密码。

也就是说我们的 WEB 应用需要实时依赖用户服务返回的用户信息,如果没有返回,这次登录将会失败。

假如这个场景我们用 MQ 代替, WEB 应用发送 MQ 消息之后,然后流程就结束了,此时 WEB 应用无法拿到用户信息。

所以说对于这种需要强依赖下游返回的场景,使用 MQ 将会带来以下不足:

  • 上游无法直接得到下游结果
  • 增加一个 MQ 组件,系统更复杂

MQ 场景

上游不关心下游结果的场景

举个例子,在我们第三方支付系统中,每支付成功一笔,都需要计算手续费。

这个场景我们显然可以使用 RPC 完成调用,但是实际上,支付系统是不关心的计费系统的结果,两个系统不存在直接强依赖的关系。

大家可以想象一下,用户实际上已经收到银行卡扣款短信了,但是支付系统因为计费系统失败,导致对外返回是失败的结果。这对于用户来讲,不能接受啊。我都付钱了,你却告诉我支付异常。

所以对于这种场景,直接使用 RPC 调用由以下几点不足:

  • 系统整体调用延时增加
  • 下游服务异常,影响上游服务。两者物理以及逻辑依赖严重
  • 若后面再增加一个下游系统,需要知道支付成功的结果,上游系统需要改动代码。这种情况对于上游情况来讲,就会很烦。明明与上游系统没有什么关系,却需要修改代码。

那一定要用 MQ 解决吗?

其实不一定,对于我们上面举的场景,我们其实可以使用异步 RPC 或者线程池异步调用 RPC 就可以解决。

毕竟增加一个 MQ, 系统就变得更加复杂,我们还要单独运维 MQ,这对于小团队来讲,工作量还是很大的。

但是这种方式,还是解决不了,增加一个下游系统,上游系统还要改动的代码囧境。

增加 MQ 解耦

这个场景使用 MQ 解耦,带来几点优点:

  • 任务一:上游系统执行时间变短
  • 任务二:上下游逻辑解耦,物理解耦
  • 任务三:最重要一点,增加一个下游服务,其只要订阅即可,上游服务无需要改动代码

数据驱动的定时任务场景

举个例子,支付公司每日都需要对账,主要目的是核实自己系统的应收的钱与支付渠道端是否一致,主要流程分为以下几步:

  • 定时任务下载渠道对账文件,下载方式可能为 Http 接口下载,也有可能 SFTP 下载
  • 定时任务解析对账文件,然后将对账数据入库
  • 定时任务将自己本端支付数据与对账数据核对

上面的定时任务使用 Spring-Schedule 调度,假设各个定时任务下载时间如下所示:

上图中三个任务,任务二需要依赖任务一完成,而任务三有需要依赖任务二完成。

我们之前使用这种模式,通常会碰到几个问题:

  • 通常 06:00 就能下载到对账文件,但是有时候渠道端多账文件延迟,就会导致任务一执行失败,这样就会后续两个定时任务也会执行失败
  • 假设任务二数据过多,执行时间过长,任务三执行时还没结束,这就导致任务三无法拿到全量数据,导致对账异常
  • 整体任务执行时间过长
  • 任务一若调整时间,可能导致任务二,任务三都需要调整时间

使用 MQ解耦

使用 MQ 解耦之后架构图如下:

这种方式,只要任务一的定时任务准时启动,任务一完成之后发送 MQ 消息,任务二收到之后就会启动任务,结束之后再发送消息给 MQ。任务三流程同任务二

使用这种方式存在优点为:

  • 下游任务只要收到消息就能立刻执行,不需要额外等待,整体任务执行时间变短
  • 上游任务时间变动,无需修改下游任务时间。我们这个例子,只需要任务一的实际即可

总结

对于上游需要关注下游返回结果的场景,不适合使用 MQ。

适合使用 MQ 的场景有:

  • 上游不管性下游结果的场景
  • 数据驱动的定时任务依赖

本文首发于: https://studyidea.cn/articles/2020/07/26/1595751010913.html

欢迎关注我的公众号:程序通事,获得日常干货推送。如果您对我的专题内容感兴趣,也可以关注我的博客:studyidea.cn