Welcome everyone

本地消息表

分布式 汪明鑫 152浏览 0评论

系统A调用系统B如何保证分布式事务

业内的操作好多都靠同步调用 + 异步扫表补偿来做

 

大家都知道rpc的调用有三态,明确返回成功,明确返回失败,中间态

 

系统A  创建红包 init 状态

同步调用 B系统扣款,扣款明确返回成功

系统A  修改红包状态为已支付paid

系统A  再调用 C系统把红包信息发给客户端展示

系统A  修改红包状态为已展示show

 

然后同时又有一个补偿任务去异步扫过去一段时间的红包表

对于init 状态的,尝试重试调系统B扣款

对于paid 状态的,尝试重试调系统C 使红包展示

由于需要不断重试,直到下游明确返回成功,当然也是需要下游保证幂等性的

(上面的这个还是比较简单的,只是举个例子,不是线上真实场景)

 

再举个例子:

比如下一个订单,一个订单下会有履约服务不断尝试去投放广告,比如每个广告计费10元,投放一个广告就会记录消耗金额

我们有一个订单表记录订单和金额,履约表记录已消耗的金额

我们怎么保证钱不会被发超呢?

由于分布式三态的存在,我们需要引入另一张表广告投放流水表

流水表记录了对应的订单id和下单用户id以及流水的状态

系统拿到一条需要投放的广告,先落一条init状态的流水

流水推进任务扫这些流水,发现当前钱还没花完,就把流水置为 DOING,资源已经ready随时可以投放,可以理解成是在途的金额

此时还需要事务的把增加履约表的投放金额,这样钱就不会被花超了

扫到流水是 DOING的,此时去调用rpc去投放广告,明确返回成功,就把流水置为 DONE

明确返回失败,就把流水置为 ROLLBACK,  并事务的把上面履约表已增加的金额回滚掉

投放广告的幂等key就是订单id + 流水id

有了上面2个例子,应该能够很好的理解本地消息表了,如果遇到跨系统调用又需要保证系统数据的准确性就可以用起来啦

转载请注明:汪明鑫的个人博客 » 本地消息表

喜欢 (0)

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz