分布式事务

###事务：
用户定义的一系列数据库操作，这些操作可以视为一个完整的逻辑处理工作单元，要么全部执行，要么全部不执行，是不可分割的工作单元

###分布式事务：
分布式事务是指会涉及到操作多个数据库（服务）的事务。其实就是将同一个数据库（服务）事务的概念扩大到了对多个数据库（服务）的事务。目的是为了保证分布式系统中的数据一致性。

###XA规范：
总之一句话：就X/Open DTP组织定义的事务协调者与数据库之间的接口规范（即接口函数），事务协调者用它来通知数据库事务的开始，结束以及提交、回滚等。
XA接口函数由数据库厂商提供；
XA规范的实现：
分布式集群情况下，一般加代理层来充当TM的角色，实现对事务的支持。
二阶段提交协议（2PC)和三阶段提交协议（3PC)就是根据这一思想衍生出来的。
两阶段提交主要保证了分布式事务的原子性：即所有节点要么全做要么全年不做

###二阶段提交的缺点：
1.单点故障：（协调者故障，事务失败）；
2.阻塞资源：（占用数据库连接，性能低下，执行完一阶段提交之后，参与者需要保持数据库连接来保证二阶段的提交或者回滚）
3.数据不一致：（二阶段参与者中部分节点出错造成数据不一致）

###2pc缺点的解决：
1.多节点部署协调者；
2.记录undolog,在一阶段的时候就执行commit操作并释放资源，二阶段成功，则删除undolog,失败则使用undolog回滚数据并删除undolog;
3.人工介入，使用脚本，要么将数据前滚成都commit成功的状态，要么回滚成初始没有执行的状态；

###三阶段提交：
1.can commit：参与者检查sql是否可以执行成功，将检查结果返回给协调者；
2.pre commit：如果一阶段的返回结果都是成功，协调者发送指令通知参与者执行sql,参与者执行sql,并向协调者反馈执行结果
3.do commit：协调者根据二阶段的sql执行结果，如果全部成功，则发送commit指令通知参与者提交，否则发送回滚命令；

###3pc相对与2pc解决的问题：
1.can commmit阶段减少了因为sql出错而占用数据库资源的情况
2.每个参与者都有一个超时的机制，也就是参与者子规定时间内没有收到协调者的指令，则执行abort commit放弃提交；

###TCC(Try Confirm Cancel)解决方案：
1.第一正常执行业务逻辑，可以包含多种的数据库操作（redis,mysql），并且落库commit;
2.如果一阶段存在某个流程出错，则对已经执行成功的流程执行逆操作使数据还原到执行之前；
3.如果一阶段全部执行成功，则事务正常结束；

###最大努力通知方案：
在我们去调用第三方支付系统（支付宝，微信，华为应用内支付）的时候，我方app调用充值接口，调起支付页面，我方App发起支付请求，第三方支付系统完成支付后，第三方需要将充值结果回调给我方的后端系统，我方后端系统更新充值状态； 但是这里就会存在事务问题，第三方充值系统需要保证回调到我方系统，第三方充值系统是我们无法左右的，不可能说让别人改代码配合我们左二阶段，三阶段提交的，所以说第三方支付系统一般为了保证接口能够回调到我方系统，会多次重试回调我方系统（所以说是尽我最大的努力去通知你），但是不是一直重试，这样话黑客不断充值1分钱，不断让系统进行通知，系统很容易崩溃，然后第三不光会重试回调，并且提供主动查询第三方系统支付系统充值结果的接口供调用方使用，第三方支付系统一般会采用这种方案来保证了整个支付流程完整调用完成；