优秀的项目都由同步、异步和定时任务三种处理模式相辅相成。当属异步编程充满坑点。
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,避免消息重新进入队列
- throw new AmqpRejectAndDontRequeueException("error");
但更希望对同一消息,能够先进行几次重试,解决因为网络问题导致的偶发消息处理失败,若依旧失败,再把消息投递到专门设置的DLX。对于来自DLX的数据,可能只是记录日志发送报警,即使出现异常也不会再重复投递。
逻辑如下
针对该问题,我们来看
Spring AMQP的简便解决方案
- 定义死信交换器、死信队列。其实都是普通交换器和队列,只不过专门用于处理死信消息
- 通过RetryInterceptorBuilder构建一个RetryOperationsInterceptor以处理失败时候的重试。策略是最多尝试5次(重试4次);并且采取指数退避重试,首次重试延迟1秒,第二次2秒,以此类推,最大延迟是10秒;如果第4次重试还是失败,则使用RepublishMessageRecoverer把消息重新投入一个DLX
- 定义死信队列的处理程序。本案例只记录日志
代码
执行程序,发送两条消息,查看日志:
- msg2的4次重试间隔分别是1秒、2秒、4秒、8秒,再加上首次的失败,所以最大尝试次数是5
- 4次重试后,RepublishMessageRecoverer把消息发往DLX
- 死信处理程序输出了got dead message msg2。
虽然几乎同时发俩消息,但msg2在msg1四次重试全部结束后才开始处理,因为默认SimpleMessageListenerContainer只有一个消费线程。可通过增加消费线程避免性能问题:
直接设置concurrentConsumers参数为10,来增加到10个工作线程
也可设置maxConcurrentConsumers参数,让SimpleMessageListenerContainer动态调整消费者线程数。
小结
一般在遇到消息处理失败的时候,可设置重试。若重试还是不行,可把该消息扔到专门的死信队列处理,不要让死信影响到正常消息处理。