分布式事务——理论篇

         数据库事务的四个原则ACID 原子性，一致性，隔离性，持久性

        微服务的软件开发，数据库相互分离，在调用多个服务的过程中，涉及到多个数据库，数据库本身事务无法满足多个数据源之间的ACID。因此引出目前业界比较难处理的分布式事务问题。

分布式事务

原则CAP

一致性，可用性，分区容错性。

在分布式事务处理过程，不可能同时满足上述三者，只能同时满足两者，后续通过其他方案来弥补，到达最终一致性。

理论BASE

通过控制软状态的变化，到达最终一致性效果

相关协议

XA 两段式协议

         XA有协调者，负责通知按链路执行通知所有参与者准备执行，待收到所有参与者都可以执行成功消息，通知参与者正式提交。因为XA协议是链路顺序执行，很容易因为某个端点超时处理，造成“同步阻塞”，影响之后链路的正常执行，而造成整个事务失败。

基于两段式产生的三段式协议

       对于二阶段中同步阻塞问题优化，引入超时机制，解决阻塞问题。三阶段分为预备，准备，终止事务

      在预备，准备阶段任何参与者回复执行异常或者等待超时，则直接终止事务。但是等待超时，其他事务回滚，超时者本身却执行成功，也存在造成数据不一致性的情况。

具体的实现方案

1、最终一致性（可靠消息服务）

方案特点

可独立部署，独立伸缩（扩展性）

兼容所有实现JMS标准的MQ中间件

能降低业务系统与消息系统间的耦合性

可在数据可靠的前提下确保最终一致性

利用可靠消息服务的时候，注意处理逻辑过程的幂等性，防止因为网络波动，重复请求，分布式消息消费，用户重复操作，未关闭的重试机制等原因造成的逻辑重复处理。

在幂等性的处理方案分为以下几种

1)、分布式锁

2)、数据库唯一索引

3)、状态流转——状态机控制

4)、乐观锁，多版本控制

5)、select + insert （先查后处理，此方式对于高并发场景不建议使用）

2、TCC （阿里框架）

本质上是二阶段提交，实现最终一致性。

try confirm cancel，在try预处理过程，通过执行结果，选择confirm或者cancel二者之一。

方案特点

不与具体的服务框架耦合

位于业务服务层，而非资源层

灵活选择业务资源的锁定粒度

适用于强隔离性，严格一致性要求的业务场景

适用于执行时间较短的业务

3、最大努力通知型方案

适用于跨平台,尽量去处理通知，即便失败，影响不大的场景

在实际的业务场景中一般这几种情况配合使用，能满足具体的业务场景。