分布式事务的解决方案

一，分布式事务产生的背景

如图1所示，服务的SOA化

2，数据库的分库分表

在分布式情况下出现的事务问题，就叫做分布式事务

大部分的事务，都是属于数据库事务，事务是运行在数据库上的一个逻辑单元

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

原子性atominc：事务必须是原子的工作单元，要么成功，要么失败

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

隔离性（Isclation）：并发事务所做的修改必须和其他事务所做的修改是隔离德

 持久性持续时间：事务完成后，对系统的影响是永久性的。

 

二，MySQL的里事务处理过程

1，记录重做和撤消日志文件，确保日志在磁盘上的持久化

2，更新数据记录

3，提交事务，重做写入提交记录。

 

三，分布式事务

如图1所示，数据库分库分表

X / OpenDTP事务模型

X / Open DIstrbuted事务处理参考模型

在X / Open是一个组织机构，定义出的一套分布式事务标准，定义了规范的API接口

2PC（2阶段提交）用来保证分布式事务的完整性

X / OpenDTP角色

AP：节点（应用程序）应用程序

RM：资源管理器（数据库）资源管理器这样的数据库要实现XA定义的接口

TM：事务管理器，事务协调者事务管理器atomikos模型

2PC协议：两阶段提交会生成tm.log日志文件

1，提交事务请求（投票阶段）

2，执行事务请求

2pc带来的问题：①数据一致性，网络异常导致协调者发生提交异常，只有一部分参与者接收到请求，如果未提交部分突然宕机，就会出现分布式节点数据不一致的问题

②同步阻塞

3PC协议：相比2PC协议增加了超时机制，在cancommit阶段终止，要达到数据的最终一致性

cancommit

预先承诺

docommit

XA / JTA：JTA（Java Transaction API）为J2EE平台提供了分布式事务服务。要用JTA进行事务界定，应用程序要调用javax.transaction.UserTransaction接口中的方法

CAP理论：

阶段一：提交事务请求

1，TM向所有的AP发送事务内容，询问是否可以执行事务的提交操作，并等待各个AP的相应

2，执行事务，各个AJP节点执行事务操作，将撤消和重做信息记录到事务日志中个，尽量吧提交过程中所消耗时间的操作和准备都提前完成后确保后续事务提交的成功率

3，各个AP向TM反馈事务询问的响应。

 

四，互联网解决方案

保证消息不重复消费：

               ①幂等校验：通过数据库层面，新建一个mq_receive表（密钥唯一密钥）密钥为唯一索引，如果消息重复，那么第二条会插入失败，这是入口层面的幂等

  ②日志表来判断，或者通过状态锁来判断;通过记录一个消费表，记录这个消息的状态状态

保证最终一致性的模式：①查询模式：提供一个接口，查询消息是否成功，返回当前操作是否成功状态，衰减查询（衰减因子5s 10s 20s）

 ②补偿模式：自动恢复：自动充值回滚原有操作

通知运营：人工补偿

通知技术：监控，预警（修复数据）

TCC事务（DTS事务架构）：数据库最终一致性的方案。

尝试：冻结账户余额（订单金额），商户不要动

确认：扣减账户余额，商户余额增加

取消：确认或者尝试阶段出现问题后，就解冻账户余额