mq要如何处理消息丢失、重复消费?

小豆丁 10月前 ⋅ 291 阅读

如果要你实现一个支付宝向余额宝转账的功能,比如:账户a从支付宝转出5000余额宝转入5000,该怎么做呢?

可能有些人会说,这还不简单,直接上图 https://mmbiz.qpic.cn/mmbiz_png/uL371281oDEKVGOq0yCdicarmicdRdpM38gReFicicbrgrrPZHyz6DxrnhSJjiaE2eQ4VGVW9iasWjyR8ib05ubJVw4rw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1

支付宝先给账户a减5000,调用余额宝的接口给余额宝的账号b加5000。

用这种方式正常情况下是可以的,如果出现以下问题该怎么办呢? 调用余额宝api时网络失败了 调用余额宝api时网络超时了 如果余额宝api业务逻辑比较复杂,耗时比较长,用户需要长时间的等待才有结果,用户体验不好

有人说:如果调用余额宝api时网络失败了,对接口进行重试不就可以解决问题了。

答:你是用同步重试,还是异步重试呢? 如果用同步重试,即在调用余额宝api时获取返回值,如果发现失败立刻重试3次。调用一次余额宝api的耗时为n秒,重试3次的耗时则为3n秒,接口响应时间增加了两倍,增加了接口超时的风险。如果重试3次之后,还是失败该怎么处理? 如果用异步重试,第一次调用余额宝api时,不管是成功还是失败,都直接给用户返回成功。如果是失败,后台开启一个线程,不断重试一直到成功为止。如果在不断重试的过程中服务器重启了,该怎么办?

又有人说:如果调用余额宝api时网络超时了,不知道上次请求是成功还是失败,再重试一下不行吗?

答:不是不行,第一.余额宝必须做幂等性设计,不然余额宝这边多转入5000怎么办?余额宝肯定不会犯这种错误。第二.同样会面临如果调用余额宝api时网络失败了的问题。

再有人说:如果余额宝api业务逻辑比较复杂,耗时比较长,用户需要长时间的等待才有结果,用户体验不好。改成异步就可以解决这个问题了。

答:改成异步可以提前告知用户结果,然后在后台通过补偿机制不断的重试,让数据达成最终一致性,这种方式对用户体验可能确实要好一些。异步处理又分为:开启线程 和 使用mq。线程处理有比较致命的弊端,如果服务器重启,线程里的数据会丢失。

接下来,我们的重点放在mq上。 https://mmbiz.qpic.cn/mmbiz_png/uL371281oDEKVGOq0yCdicarmicdRdpM38iaxhF74EkumAiaSKWqPJnpdsGonbn9qhx9AdyklDJia6npNjiaOlswITMg/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1

余额宝给账户a减了5000之后,给指定topic1发一条消息,然后余额宝从topic1消费这条消息,给账户b加5000。

对于问题1,如果余额宝处理失败了,比如像rocketmq这类消息处理框架会把消息放入重试队列重试16次,不需要业务代码做额外的工作。

对于问题2,如果服务器重启了,由于消息保存在服务端的磁盘上,不会丢失,客户端可以通过offset从服务端重新获取消息,它能够保证消息至少被余额宝消费一次。

对于问题3,支付宝给账户a减了5000发送完消息之后,可以直接返回成功,然后余额宝作为消费者在后台默默执行,一直到成功为止。

那么问题又来了: 如果余额宝消费了消息,业务处理失败了怎么办?这个就是所谓的消息丢失。

要解决消息丢失就需要建一张消息发送表,如图: https://mmbiz.qpic.cn/mmbiz_png/uL371281oDEKVGOq0yCdicarmicdRdpM383y46whrquvPzceCvpfJJScUfIcYPKjX1VgR7BWIMXNueibGfznROz5g/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1

   支付宝从账户a减5000,接着往本地消息表中写入一条消息记录,confirm_status为待确认,然后发送mq消息。注意,支付宝这边的扣款和写本地消息表要在同一事务中。

   余额宝消费消息给账户b加5000之后,调用支付宝消息确认api,修改confirm_status为已确认。

    如果余额宝这边消息丢失了,支付宝有个job会每个5分钟扫描一次本地消息表中confirm_status为待确认状态的记录,重新发送一次消息,这样余额宝又可以重新处理了。

那么还有个问题: 余额宝这边处理成功,但是由于调用 支付宝消息确认api失败,导致支付宝的job重新发送消息,余额宝重复消费了。这个就是所谓的重复消息。

重复消费要如何解决呢? https://mmbiz.qpic.cn/mmbiz_png/uL371281oDEKVGOq0yCdicarmicdRdpM38XYODG9MtmqNwLCroSuAe5CwYJdjn8Ts9yOzTA4YNCqO9zEtoGNp3Vw/640?wx_fmt=png&wxfrom=5&wx_lazy=1&wx_co=1

    余额宝也增加一个本地消息表,记录业务处理成功的消息。当然余额宝的账号操作和本地消息表也要在同一个事务中。    
    
    余额宝消费消息之后,先从余额宝的本地消息表中查一下,该消息有没有消费过,如果已经消费过了,则直接调用支付宝消息确认api,修改confirm_status为已确认,避免下次支付宝的job重复发消息。如果从余额宝的本地消息表中查到没有消费,则给账户b增加5000,同时往本地消息表写一条记录,然后调用支付宝消息确认api。

   总结:通过在mq的生产者和消费者两端分别增加本地消息表,并且在生成者端增加定时job扫描待确认状态的记录,重新发送消息,可以解决:消息丢失 和 重复消费 问题。当然实际的支付宝向余额宝转账的场景更复杂,在高并发的情况下,可能需要用分布式锁,防止金额异常。

全部评论: 0

    我有话说: