分布式事务

1.数据不一致性产生原因

1.1.数据分散在多处： 多个DB; DB和缓存

     案例：二手交易平台案例：用户、商品、交易等功能

              电商平台购买商品：下单（订单库）-》减库存（商品库）-》支付（交易库）

2.分布式事务分类

2.1.刚性分布式事务

     强一致性

      XA模型 ->ACID 

      CAP -> CP

2.2.满足传统事务特性：

       ACID

2.3.XA模型：

      XA规范由AP(application), RM(数据源管理也就是数据库），TM（事务管理）组成    

    2.3.1.2PC-》2阶段提交

                同步阻塞模型， 数据库资源锁定时间过长，全局锁（隔离级别串行化），并发低，不适合长事务场景 

2.2.柔性分布式事务

      最终一致性

      CAP（AP）、BASE理伦

     2.3.1.CAP

           分布式环境下p一定需要，CA权衡折中

     2.3.2.BASE理论

            BAseically Available -基本可用

            Soft state->柔性状态 

            Eventually consistency 最终一致性

3.柔性事务

3.1.TCC模型

     Try - Confirm -Cancel

     TCC模型完全交由业务实现，每个子业务都需要实现 Try-Confirm-Cancel接口

              资源锁定交由业务

     Try：尝试执行业务，完成所有业务检查，预留必要的业务资源

      Confirm：真正执行业务，不再做业务检查

      Cancel：释放Try阶段预留的业务资源

案例：

      汇款服务、收款服务案例

3.2.Saga模型

       Saga模型把一个分布式事务拆分成多个本地事务，每个本地事务都有执行模块和补偿模块（对应TCC中的Confirm,Cancel)

       当Saga子事务T1,T2........,Tn都有对应的补偿定义C1,C2......,Cn-1那么Saga系统可以保证

                 事务序列T1,T2,.........,Tn得心完成（最佳情况 ）

                 或者序列T1,T2.......,Tj,Cj-1,.......,0<j<n 得心完成 

      Saga隔离性

                     业务层控制并发，在应用层加锁，应用层预先冻结资源等

      Saga恢复方式：

                    向后恢复：补偿所有已经完成的事务，如果任一子事务失败

                   向前恢复：重试失败的事务，假设每个子系统事务最终都 会成功

4.异步场景分布式事务设计 

4.1.方案一：业务方提供本地操作成功回查功能

      事务消息：MQ提供类似X/Open XA分布式事务功能 ，通过MQ事务消息能达到 分面式事务的最终一致

      半消息：暂不能投递的消息，发送方已经将消息成功发送到了mq 服务器，但是服务端未收到生产者对该消息的二次确认，此时该消息被标志成“暂不能投递“状态，处于该种状态下的消息即半消息

       消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，MQ服务端通过扫描发现某条消息长期处理”半消息“时，需要主动向消息生产者询问该消息的最终状态（Commit或者是Rollback），即消息回查

4.2.MQ分布式事务设计方案：

MQ事务消息设计事务消息作为一种异步确保事务，将两个事务分支通过MQ进行异步解耦，MQ事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：

 

缺点：

第一：MQ要提供半消息遍历

第二：业务方要提供成功回查功能 

第三：发送消息非幂等

 4.2.方案二：本地事务消息表

本地操作和发送消息通过本地事务强一致性

              本地事务操作表， 本地事务消息表（msgid, content, topic, status)

业务入侵较小，线上常用的方案。