java分布式事务

java分布式事务

不同的连接

事务:数据库 *** 作的最小单元

 分布式事务:跨越connect的事务

CAP理论

• 一致性:Consistency
  • 集群的各个节点数据都是一致的,因此可以向任意节点读写数据,并且总是得到相同数据
• 可用性:Availability
  • 可用性表示总是能够访问集群(读/写),即便集群中某个节点宕机了
• 分区容忍性:Partition toleranc
  • 数据库之间网络连接,但是宕机了,变为分区依然可以进行数据库 *** 作

  1.一旦出现了分区的情况下,需要保证数据的一致性,就要牺牲数据的可用性

   2.一旦出现分区的情况下,如果保证集群的可用性,就牺牲了一致性;

        满足CA-->单体应用

刚性事务:遵循ACID的强一致性

        追求单体事务的完成度

        XA/2PC

根据第一个阶段的返回结果

 缺陷

        1.第一阶段待修改的数据会被加上排它锁,导致在没有释放锁的时候其他执行会等待

        2.无法保证数据的强一致性

(也就是导入一个事务管理器,让管理器管理)

柔性事务:最终一致性

定义:遵循base理论,最终一致性;与刚性不同,允许这一定时间内,不同节点数据不一致,但是要求数据最终一致;

 TCC事务(相当于人工回滚)

        服务化的二阶段编程模型() :XP/2PC是数据库的两阶段,TCC是业务的二阶段

 

try里是一个执行,/confirm/i接口再执行

如果try失败了,那么执行 Cancel

也就是把业务分为了两个阶段,数据库是无法感知的,没有数据库阻塞

如果/confirm/i失败了,会不断重试达到最终一致性

(业务二段,类似回滚)

本地消息表

(单项目 *** 作变为事务+两张表+定时 *** 作)

 变成了本地的事务,(本地消息表),让1与2变成了事务,让定时任务发送消息来进行库存服务

 库存服务方面

 如果库存扣减失败,由于本地事务不会发送库存扣减的消息,余额方会不断重试,最终一致性;

现在存在的问题:扣减成功,但是发消息失败,会导致重试之后扣除两次库存

接口幂等性:
        一个事件,在相同条件下,做一次与多次没有区别

对库存扣减实现接口幂等性

再添加一张表(建立扣减库存与扣减库存记录表的本地事务关系)

 

 总结:

        1.利用本地消息表,把扣除余额与插入消息表变为事务,(对此可以保证如果扣除失败,不插入,定时扫描不到就不发送消息)成功

                1.1如果成功,定时任务扫描表格,发现没有具有事务没有完成的任务,会不断发送消息,进行扣减库存(保证最终一致性)

        2.如果余额扣减成功,并发送消息,库存表执行扣减库存(如果失败,余额会不断重试发送),为了防止出现扣库存但是没有成功发送消息(得到一个扣减库存的记录表),利用这个表可以记录自身扣减的行为防止多次扣减库存如果二者都成功,再发回扣减库存成功消息给余额,余额表修改本地消息记录;

==>完成事务

 思想:1.可以把方法通过数据库的加表事务变成事务方法

        2.定时方法,重试的思想

RocketMQ事务消息

消费失败RMQ会重试16次 4小时 

1.上游失败执行4回滚,丢弃消息

2.

如何保证？（记下来，要考）

• MQ假如投递消息到MQ订阅方失败了，或者MQ订阅方消费消息失败了，那么MQ会把该消息丢入重试队列中，会重试发送该消息，默认16次，直到消息被消费成功为止
• 假如在16次之后该消息还没有被消费成功，那么MQ会再次把该消息丢入MQ死信队列中，对于死信队列的消息，我们需要手动去干预，让他消费成功（例如从后台管理系统手动（或者是定时任务）把死信队列中的消息拿出来，然后手动去执行 *** 作，执行完成之后把消息从死信队列中删除掉）

3.4 事务框架介绍
阿里GTS