分布式专题（六）分布式事物

数据库事务要满足几个要求：ACID

Atomic(原子性)     事务必须是原子的工作单元

Consistent(一致性)  事务完成时，必须使所有数据都保持一致状态

Isolation(隔离性)    并发事务所做的修改必须和其他事务所做的修改是隔离的

Duration（持久性） 事务完成之后，对系统的影响是永久性的

 

CAP理论

CAP理论是：分布式系统在设计时只能在一致性(Consistency)、可用性(Availability)、分区容忍性(Partition
Tolerance)中满足两种，无法兼顾三种
CAP有哪些组合方式？
1、CA：放弃分区容忍性，加强一致性和可用性，关系数据库按照CA进行设计。
2、AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多NoSQL数据库按照AP进行设计。
说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允
许暂时的数据不一致，只要最终在用户接受的时间内数据 一致即可。
3、CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按CP进行设计，比如跨行转账，一次转
账请求要等待双方银行系统都完成整个事务才算完成。
 

在分布式系统设计中AP的应用较多，即保证分区容忍性和可用性，牺牲数据的强一致性（写操作后立刻读取到最
新数据），保证数据最终一致性。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的
时间内退款事务走完即可。
 

2PC（略） 两阶段提交锁定时间长，对性能影响很大，不适合解决微服务下的分布式事务问题

  2PC升级版：tcc：由事务管理器来调用两方的本地事务的try接口，都成功才能让各自confirm。 问题是入侵性太强

3PC（略）

2PC 和 3PC 都是存在问题的，一般采用AP理论，采用基于消息的最终一致性

 

 

---

使用消息队列（MQ）解决分布式事务（推荐）

各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛，而且比较可靠。不过这种方式技术实现的难度比较大

1、订单服务和库存服务完成检查和预留资源。
2、订单服务在本地事务中完成添加订单表记录和添加“减少库存任务消息”。
3、由定时任务根据消息表的记录发送给MQ通知库存服务执行减库存操作。
4、库存服务执行减少库存，并且记录执行消息状态（为避免重复执行消息，在执行减库存之前查询是否执行过此
消息）。
5、库存服务向MQ发送完成减少库存的消息。
6、订单服务接收到完成库存减少的消息后删除原来添加的“减少库存任务消息”。
实现最终事务一致要求：预留资源成功理论上要求正式执行成功，如果执行失败会进行重试，要求业务执行方法实
现幂等。
优点 ：
由MQ按异步的方式协调完成事务，性能较高。
不用实现try/confirm/cancel接口，开发成本比TCC低。
缺点：
此方式基于关系数据库本地事务来实现，会出现频繁读写数据库记录，浪费数据库资源，另外对于高并发操作不是
最佳方案。
 

 

1、支付成功后，订单服务向本地数据库更新订单状态并向消息表写入“添加选课消息”，通过本地数据库保证订单
状态和添加选课消息的事务。。
2、定时任务扫描消息表，取出“添加选课任务“并发向MQ。
3、学习服务接收到添加选课的消息，先查询本地数据库的历史消息表是否存在消息，存在则说明已经添加选课，
否则向本地数据库添加选课，并向历史消息表添加选课消息。这里选课表和历史消息表在同一个数据库，通过本地
事务保证。
4、学习服务接收到添加选课的消息，通过查询消息表判断如果已经添加选课也向MQ发送“完成添加选课任务的消
息”，否则则添加选课，完成后向MQ发送“完成添加选课任务的消息”，
5、订单服务接收到完成选课的消息后删除订单数据库中消息表的“添加选课消息”，为保证后期对账将消息表的消
息先添加到历史消息表再删除消息，表示此消息已经完成。
 

 

 

 

代码参考https://gitee.com/q975583865/xc_edu （xc-service-manage-order 和  xc-service-learning）

文档参考学成在线19章