分布式事务

2023.8.17

先假设我们有一个订单系统，收到请求之后，我们要干这几件事：

1.生成订单

2.清空购物车

3.生成积分

4.1号账户扣款

5.2号账户收款

 

收到请求的服务是A，最慢的办法，我们在这个请求的接口中串行的调用其他服务中的接口，有异常，或者设计好请求的返回（理想情况，都有可以拿到的返回），就回滚。

进一步讲，可以把这几步操作中必要的做串行化，其他的可以整成异步的，可以用消息队列，设计好重试机制，收到完成消息往下走，如果收到对面的某个回调请求再去处理这样.

 

2023.8.24

1.单体架构下的多数据源场景也可能产生分布式事务问题

　　可以采用jta+Atomikos解决——整体管理多个事务

 

2023.8.26

1.正式的分布式架构，考虑mq和seata解决。

 

2.LCN模式

　　假设场景是一个支付服务接口做事务发起者，过程中调用积分服务（做事务参与者）

　　现在外面有一个事务协调者，事务发起者、参与者都与之建立长连接

　　在支付接口使用RPC调用积分服务对应接口时，在请求头中加入一个事务协调者分发的“全局事务分组id”

　　最后发起者完成或报错通知协调者，协调者提交或回滚。

　　该模式的弊端：

　　　　数据源假关闭、事务不提交、导致数据源行锁一直被占用

　　考虑事务协调者也有可能宕机，最好构建事务协调者集群。

　　如果说协调者集群全部宕机，参与者根据超时时间会判断参与失败，回滚，后续可以通过其他方法补偿对应的业务功能。

 

3.Seata

　　基于undolog做逆向回滚

　　执行某个新增、修改sql语句的时候，记录前置前置镜像、后置镜像，放到undolog表中。

　　AT模式可能存在短暂的脏读问题

 

4.RocketMQ

　　最终一致性，还是上面的支付-积分场景

　　支付服务作为消息生产者，必须保证消息到达mq服务端

　　　　ACK消息确认机制

　　　　同步消息或者异步消息

　　如果生产者投递失败，准备好一个定时任务步长对应的业务功能

　　在mq服务端，同步刷盘可以严格确认消息到达服务端。

　　消息消费者，也就是积分服务，要使用手动ACK机制确认消息已经完成。

　　其中消息中可以存一个全局唯一的id，保证消息不被重复消费

 

2024.6.30

1.使用MQ来实现分布式事务并不是强一致性的

https://blog.csdn.net/Saintmm/article/details/119826091