在单库单系统中,不需要对事物进行特殊的处理,回滚即可。当一个大系统拆分多个子系统微服务之后,由于事物不支持跨系统处理,就有了分布式事物的问题。
解决分布式事物常见的方案有以下几种:
- 基于消息中间件解决,比较常用的方案,可靠性高,适合于对实时性要求不是很高的应用场景。
- TCC(try confirm cancel)事物补偿性方案,实时性高,个人理解为直接通过rpc交互,如发生异常或者业务不满足,直接通过rpc作数据还原请求,需要写好事物还原接口。
- 最大努力通知型方案,经典案例微信支付宝支付回调,需做好查重,保持幂等性。
幂等性
幂等性是对接口而言,接口的幂等性是指在多次调用的情况下,得到的结果都能保持一致,业务需求一致。查询接口天然幂等,赠删改都要借助其他来保证幂等性。
保证幂等性方案有两种,去重表和全局唯一id。
- 去重表:在支付场景中,每个订单只能成功支付一次,可以建一张去重表,保存支付成功的订单信息,并且保证订单id唯一,外部服务请求支付订单时,首先在去重表中查询是否存在该订单,存在则不执行,典型的例如对接微信支付、支付宝支付、银企直连。
- 全局唯一id:根据业务和内容生成对应的唯一id,存储起来,比如存储在redis,执行业务之前根据这个全局id判定是否已经处理过,唯一id可用业务记录的关键内容、时间戳、记录id、uuid等生成。
使用消息中间件RocketMQ解决分布式事物
- 系统A作为消息生产者Producer,A在执行本地事物前会向消息中间件RocketMQ投递一条消息,Mq保存该消息,并且消息状态为Prepared,不投递给下游消费者系统B;
- Mq发送确认消息至A,并且开始计时等待A的响应,若超时,Mq会不断向A发送消息确认;
- A收到确认应答之后开始执行本地事物;
- 如果A本地事物执行成功,则向Mq发送Commit请求,Mq收到请求后,便向B投递消息,B开始执行事物;
- 如果A本地事物执行失败,会向Mq发送Rollback请求,Mq收到Rollback后,会删除消息,不再向B投递消息,流程结束;
- B收到消息后开始执行本地事物,并把执行结果反馈至Mq;
- 若反馈超时,Mq触发超时机制,Mq会不断向B重复投递消息,直到B成功消费消息,此时需要注意幂等性问题;,
- 若B成功执行本地事物,反馈Commit确认消息至Mq,Mq清除对应消息数据,分布式事物成功执行完;
- 若B未成功执行事物或者业务不满足,反馈消费失败给Mq,此时,Mq会重新向B投递消费的消息,直到消费成功,当超过设定重试次数仍然失败,此时则需要人工处理;
当B执行事物失败,为什么不回滚A的事物?
上述流程可知,当B开始执行事物时,代表A的事物成功的执行了,如果再去回滚A的事物,可能会出现以下问题,需要增加回滚事物的请求接口,无疑加大了系统的复杂度和开发成本,而且保证不了回滚事物接口的成功执行,原本一个问题变成了两个问题,会引起更多bug的可能性比较高,大成本解决小概率事件。