用了这么久的RabbitMQ异步编程竟然都是错的!

开发 前端
RabbitMQ虽可将消息落地磁盘,即使MQ异常消息数据也不会丢失,但异步流程在消息发送、传输、处理等环节,都可能发生消息丢失。所有MQ都无法确保百分百可用,业务设计都需考虑不可用时异步流程将如何继续。

[[354956]]

 优秀的项目都由同步、异步和定时任务三种处理模式相辅相成。当属异步编程充满坑点。

1 适用场景

1.1 服务于主流程的分支流程

在注册流程中,数据写DB是主流程,但注册后给用户发优惠券或欢迎短信是分支流程,时效性也不强。

1.2 用户无需实时看到结果

比如外卖下单后的配货、送货流程完全可异步处理,每个阶段处理完成后,再给用户发推送或短信让用户知晓即可。

1.3 MQ

任务的缓冲的分发,流量削峰、服务解耦和消息广播。

当然了异步处理不仅仅是通过 MQ 来实现,还有其他方式

比如开新线程执行,返回 Future

还有各种异步框架,比如 Vertx,它是通过 callback 的方式实现

2 异步处理之坑

2.1 异步处理需做消息补偿以闭环

RabbitMQ虽可将消息落地磁盘,即使MQ异常消息数据也不会丢失,但异步流程在消息发送、传输、处理等环节,都可能发生消息丢失。所有MQ都无法确保百分百可用,业务设计都需考虑不可用时异步流程将如何继续。

因此,对于异步处理流程,必须考虑补偿或建立主备双活流程。

2.1.1 案例

用户注册后异步发送欢迎消息。

 

  • 用户注册落DB为同步流程
  • 会员服务收到消息后发送欢迎消息为异步流程

  • 蓝线

           MQ异步处理(主线),消息可能丢失(虚线代表异步调用)

  • 绿线

          补偿Job定期消息补偿(备线),以补偿主线丢失的消息

  • 考虑极端的MQ中间件失效场景

          要求备线的处理吞吐能力达到主线性能

代码示例

UserController 注册+发送异步消息。注册方法,一次性注册10个用户,用户注册消息不能发送出去的概率为50%。

MemberService 会员服务监听用户注册成功的消息,并发送欢迎短信。使用ConcurrentHashMap存放那些发过短信的用户ID实现幂等,避免相同的用户补偿时重复发短信


对于MQ消费程序,处理逻辑须考虑去重(支持幂等):

  • MQ消息可能会因中间件本身配置错误、稳定性等原因出现重复
  • 自动补偿重复
  • 比如本例,同一消息可能既走MQ也走补偿,肯定会出现重复,而且考虑到高内聚,补偿Job本身不会做去重
  • 人工补偿重复

出现消息堆积时,异步处理流程必然延迟。若提供补偿功能,则在处理遇到延迟时,很可能会先人工补偿,过段时间后处理程序又收到消息了,重复处理。

有次MQ故障,MQ中堆积了几十万条发放资金消息,导致业务无法及时处理,运营以为程序出错,就先通过后台进行人工处理,结果MQ系统恢复后消息又被重复处理一次,造成大量资金重复发放。

异步处理须考虑消息重复可能性,因此处理逻辑须实现幂等,防止重复处理。

接着定义补偿Job即备线操作。

定时任务,5秒做一次补偿,因Job并不知道哪些用户注册的消息可能丢失,所以是全量补偿。

  • 补偿逻辑

           每5秒补偿一次,按顺序一次补偿5个用户,下一次补偿操作从上一次补偿的最后一个用户ID开始

           补偿任务提交到线程池以“异步”处理,提高处理能力


为实现高内聚,主线和备线处理消息,最好使用同一方法。本案例的MemberService监听到MQ消息和CompensationJob补偿,调用的都是welcome。

这里的补偿逻辑简单仅为 demo,实际生产代码须:

  • 考虑配置补偿的频次、每次处理数量,以及补偿线程池大小等参数为合适值,以满足补偿的吞吐量
  • 考虑备线补偿数据进行适当延迟
  • 比如,对注册时间在30s前的用户再进行补偿,以方便和主线MQ实时流程错开,避免冲突
  • 诸如当前补偿到哪个用户的offset数据,需要落地DB
  • 补偿Job本身须高可用,可使用类似xxl-job或ElasticJob等任务系统。

运行程序,执行注册方法注册10个用户,查看日志


可见

  • 共10个用户,MQ发送成功的用户有四个:1、5、7、8
  • 补偿任务第一次运行,补偿了用户2、3、4,第二次运行补偿了用户6、9,第三次运行补充了用户10

消息补偿闭环的最高标准

能够达到补偿全量数据的吞吐量。即若补偿备线足够完善,即使直接停机MQ,虽会稍微影响处理及时性,但至少确保流程都能正常执行。

小结

实际开发要考虑异步流程丢消息或处理中断场景。

异步流程需有备线以补偿,比如这里的全量补偿方式,即便异步流程彻底失效,通过补偿也能让业务继续进行。

2.2 RabbitMQ广播、工作队列模式坑

消息模式是广播 Or 工作队列

  • 消息广播

          同一消息,不同消费者都能分别消费

  • 队列模式

          不同消费者共享消费同一个队列的数据,相同消息只能被某一个消费者消费一次。

比如同一用户的注册消息

  • 会员服务需监听以发送欢迎短信
  • 营销服务需监听以发送新用户小礼物

但会员、营销服务都可能有多实例,业务需求同一用户的消息,可同时广播给不同的服务(广播模式),但对同一服务的不同实例(比如会员服务1和会员服务2),不管哪个实例来处理,处理一次即可(工作队列模式):


实现代码时务必确认MQ系统的机制,确保消息的路由按期望。

RocketMQ实现类似功能比较简单直白:若消费者属于一个组,那么消息只会由同组的一个消费者消费;若消费者属不同组,每个组都能消费一遍消息。

而RabbitMQ的消息路由模式采用队列+交换器,队列是消息载体,交换器决定消息路由到队列的方式。

step1:会员服务-监听用户服务发出的新用户注册消息

若启动俩会员服务,那么同一用户的注册消息应只能被其中一个实例消费。

分别实现RabbitMQ队列、交换器、绑定三件套。

  • 队列使用匿名队列
  • 交换器使用DirectExchange,交换器绑定到匿名队列的路由Key是空字符串

收到消息之后,打印所在实例使用的端口。

  • 消息发布者、消费者、以及MQ的配置

使用12345和45678两个端口启动俩程序实例后,发条消息,输出的日志,显示同一会员服务两个实例都收到了消息:

所以问题在于不明

RabbitMQ直接交换器和队列的绑定关系

RabbitMQ的直接交换器根据routingKey路由消息。而程序每次启动都会创建匿名(随机命名)队列,所以每个会员服务实例都对应独立的队列,以空routingKey绑定到直接交换器。

用户服务发消息时也设置了空routingKey,所以直接交换器收到消息后,发现匹配俩队列,于是都转发消息


修复

对会员服务不要使用匿名队列,而使用同一队列。

将上面代码中的匿名队列换做普通队列:

private static final String QUEUE = "newuserQueue";@Beanpublic Queue queue() { return new Queue(QUEUE);}

这样对同一消息,俩实例中只有一个实例可收到,不同消息被轮询发给不同实例。

现在的交换器和队列关系


step2:用户服务-广播消息给会员、营销服务

期望会员、营销服务都能收到广播消息,但会员/营销服务中的每个实例只需收到一次消息。

声明一个队列和一个FanoutExchange,然后模拟俩用户服务和俩营销服务:


注册四个用户。日志发现一条用户注册的消息,要么被会员服务收到,要么被营销服务收到,这不是广播。可使用的明明是FanoutExchange,为什么没起效呢?


因为广播交换器会忽略routingKey,广播消息到所有绑定的队列。该案例的俩会员服务和两个营销服务都绑定了同一队列,所以四服务只能收到一次消息:


修复

拆分队列,会员和营销两组服务分别使用一条独立队列绑定到广播交换器

现在的交换器和队列结构


从日志输出可以验证,对每条MQ消息,会员服务和营销服务分别都会收到一次,一条消息广播到两个服务同时,在每一个服务的两个实例中通过轮询接收: 

 

异步的消息路由模式一旦配置出错,轻则可能导致消息重复处理,重则可能导致重要的服务无法接收到消息,最终造成业务逻辑错误。

小结

微服务场景下不同服务多个实例监听消息的情况,一般不同服务需要同时收到相同的消息,而相同服务的多个实例只需要轮询接收消息。我们需要确认MQ的消息路由配置是否满足需求,以避免消息重复或漏发问题。

2.3 死信堵塞MQ之坑

始终无法处理的死信消息,可能会引发堵塞MQ。

若线程池的任务队列无上限,最终可能导致OOM,类似的MQ也要注意任务堆积问题。对于突发流量引起的MQ堆积,问题并不大,适当调整消费者的消费能力应该就可以解决。但在很多时候,消息队列的堆积堵塞,是因为有大量始终无法处理的消息。

2.3.1 案例

用户服务在用户注册后发出一条消息,会员服务监听到消息后给用户派发优惠券,但因用户并没有保存成功,会员服务处理消息始终失败,消息重新进入队列,然后还是处理失败。这种在MQ中回荡的同一条消息,就是死信。

随着MQ被越来越多的死信填满,消费者需花费大量时间反复处理死信,导致正常消息的消费受阻,最终MQ可能因数据量过大而崩溃。

定义一个队列、一个直接交换器,然后把队列绑定到交换器


sendMessage发送消息到MQ,访问一次提交一条消息,使用自增标识作为消息内容


收到消息后,直接NPE,模拟处理出错


调用sendMessage接口发送两条消息,然后来到RabbitMQ管理台,可以看到这两条消息始终在队列,不断被重新投递,导致重新投递QPS达到1063。


在日志中也可看到大量异常信息。

修复方案

  • 解决死信无限重复进入队列最简单方案

          程序处理出错时,直接抛AmqpRejectAndDontRequeueException,避免消息重新进入队列

 

  1. throw new AmqpRejectAndDontRequeueException("error"); 

但更希望对同一消息,能够先进行几次重试,解决因为网络问题导致的偶发消息处理失败,若依旧失败,再把消息投递到专门设置的DLX。对于来自DLX的数据,可能只是记录日志发送报警,即使出现异常也不会再重复投递。

逻辑如下


针对该问题,我们来看

Spring AMQP的简便解决方案

  1. 定义死信交换器、死信队列。其实都是普通交换器和队列,只不过专门用于处理死信消息
  2. 通过RetryInterceptorBuilder构建一个RetryOperationsInterceptor以处理失败时候的重试。策略是最多尝试5次(重试4次);并且采取指数退避重试,首次重试延迟1秒,第二次2秒,以此类推,最大延迟是10秒;如果第4次重试还是失败,则使用RepublishMessageRecoverer把消息重新投入一个DLX
  3. 定义死信队列的处理程序。本案例只记录日志

代码


执行程序,发送两条消息,查看日志:


  • msg2的4次重试间隔分别是1秒、2秒、4秒、8秒,再加上首次的失败,所以最大尝试次数是5
  • 4次重试后,RepublishMessageRecoverer把消息发往DLX
  • 死信处理程序输出了got dead message msg2。

虽然几乎同时发俩消息,但msg2在msg1四次重试全部结束后才开始处理,因为默认SimpleMessageListenerContainer只有一个消费线程。可通过增加消费线程避免性能问题:

直接设置concurrentConsumers参数为10,来增加到10个工作线程


也可设置maxConcurrentConsumers参数,让SimpleMessageListenerContainer动态调整消费者线程数。

小结

一般在遇到消息处理失败的时候,可设置重试。若重试还是不行,可把该消息扔到专门的死信队列处理,不要让死信影响到正常消息处理。

 

责任编辑:姜华 来源: JavaEdge
相关推荐

2022-02-08 13:39:35

LinuxUNIX系统

2021-05-28 07:12:58

Mybatis面试官Java

2021-05-28 06:16:28

蓝牙Wi-FiNFC

2021-07-21 10:10:14

require前端代码

2021-11-08 10:00:19

require前端模块

2022-01-25 12:41:31

ChromeResponse接口

2018-01-31 10:24:45

热插拔原理服务器

2020-12-07 11:05:21

HttpClient代码Java

2019-11-27 10:54:43

Tomcat连接数线程池

2020-02-15 15:33:55

Python如何运作

2020-03-30 09:22:03

AI语音技术机器视觉

2021-05-27 21:18:56

谷歌Fuchsia OS操作系统

2021-04-28 11:35:06

Java框架日志

2022-08-21 14:00:11

消息中间件MQ

2020-12-21 09:43:26

微信微信功能移动应用

2018-05-09 16:25:20

关系型数据库SQL Server

2021-04-23 14:49:31

云计算混合云

2018-06-08 10:12:10

Web缓存体系服务器

2017-03-21 13:53:17

运维戴尔企业级解决方案

2020-04-06 12:39:09

微信扫一扫功能
点赞
收藏

51CTO技术栈公众号