原创

分布式事务之最大努力通知型

本文介绍分布式事务的另外一种解决方案:最大努力通知型

最大努力通知型

先来看一个业务场景

假如我们自己有一个电商系统,支持用户使用支付宝充值,流程如下:

file

用户支付流程(是一个同步的过程)

  1. 用户在浏览器发起充值请求->电商服务
  2. 电商服务生成充值订单,状态为0:待支付(0:待支付、100:支付成功、200:支付失败)
  3. 电商服务携带订单信息请求支付宝,生成支付宝订单,组装支付宝支付请求地址(订单信息、支付成功之后展示给用户的页面return_url、支付异步通知地址notify_url),将组装的信息返回给用户
  4. 用户浏览器跳转至支付宝支付页面,确认支付
  5. 支付宝携带支付结果同步回调return_url,return_url将支付结果展示给用户

支付宝将支付结果异步通知给商户

用户支付流程完毕之后,此时支付宝中支付订单已经支付完毕,但电商中的充值订单状态还是0(待支付),此时支付宝会通过异步的方式将支付结果通知给notify_url,通知的过程中可能由于网络问题,导致支付宝通知失败,此时支付宝会通过多次衰减式的重试,尽最大努力将结果通知给商户,这个过程就是最大努力通知型。

商户接收到支付宝通知之后,通过幂等性的方式对本地订单进行处理,然后告知支付宝,处理成功,之后支付宝将不再通知。

什么是衰减式的通知?

比如支付宝最大会尝试通知100次,每次通知时间间隔会递增。比如第1次失败之后,隔10s进行第2次通知,第2次失败之后,隔30s进行第三次通知,间隔时间依次递增的方式进行通知。

如果支付宝一直通知不成功怎么办?

商户可以主动去调用支付宝的查询接口,查询订单的支付状态。

为什么需要进行异步通知?

用户支付过程中,不是有个return_url么?支付宝支付成功之后会携带支付结果同步调用这个地址,那么商户直接在这个return_url中去处理一下本地订单状态不就可以了么?这种做法可以,但是有可能用户的网络不好,调用return_url失败了,此时还得依靠异步通知notify_url的方式将支付结果告知商户。

最大努力通知型用在什么场景?

分布式事务中,不能立即知道调用结果的,被调方业务处理耗时可能比较长,被调方业务处理完毕之后,可以采用最大努力通知的方式将结果通知给调用方。

最大努力通知型要有补偿机制

被调方会尽最大努力将结果通知给调用方,极端情况下有失败的可能,此时被调方需提供查询接口。

调用方对于长时间不知道结果的业务,可以主动去被调方查询,然后进行处理。

不需要通知,主动去查可以么?

可以,被调方会提供查询接口,调用方主动去查询的方式完全是可以知道结果的,不过采用通知的方式实时性更高的一些。

被调方成功之后,会立即通知调用方,但是调用方主动采用查询的方式,那么什么时候查询呢?这个度不好把握,所以两则结合更好。

推荐一个高质量的公众号

这里给大家推荐一个公众号:Java充电社,这个号中会定期发布一些高质量的java专题视频,目前已经发布了大量高质量的学习视频,大家可以去瞅瞅,欢迎关注。

file

正文到此结束
本文目录