分布式事务

1.简述

    在微服务系统中，当服务之间调用，当一个服务出现异常后，就需要别的服务已经做的操作进行回滚，这样就产生了分布式事务。分布式事务主要有cap和base理论。

CAP理论：

• Consistent: 一致性，分布式系统中的所有数据都要保持一致，例如db系统做了主从，插入及更新操作在主中做，查询在从中做，主从之间就需要同步数据，同步数据需要时间，这样就可能导致请求数据不一致。也就是说如果系统中数据一致的话，就返回给客户端结果，如果数据不一致就不返回结果，抛出异常。
• available：可用性，请求能够在合理的时间内得到合理的请求结果，该结果不是异常或者错误结果。也就是说客户端访问到分布式系统时候，必须能够得到结果，但这个结果可以是不一致的。
• Partition-tolerance ：分区容错，要求分布式系统必须可用，即使部分节点出现延迟或者错误，也不能全部挂掉，这是分布式系统的基本要求。

CAP理论中：p比较容易满足，由于c的特殊性，c和a不可同时满足，所以一般系统需要根据场景选择支持pc或者pa，支持c的适合要求数据非常准确的场景如账户的余额，支持a的适用提高用户体验的场景。

BASE理论：

• basic available 基本可用：保证核心服务正常提供服务，允许部分功能失效
• soft status 软状态: 允许分布式系统中数据处于中间状态，但不影响系统的可用性，此状态系统不满足一致性。
• eventually 最终一致性：经过软状态后，系统能够达到一致性状态，虽然有一定的延迟，但能够保证服务的高可用。

BASE理论的软状态和最终一致性解决了CAP理论中一致性和可用性的矛盾，保证延迟一定时间后系统的最终一致性。

2.基于消息队列的分布式事务

    该方式利用消息队列的发送及接收确认机制，对消息队列要求比较高。该方式实现保证最终一致性，系统可以处于数据不一致的软状态，此种实现方式性能也比较高。但数据的最终一致性必须mq的高可用，所以这儿就可以设置mq集群，保证消息成功发送到mq集群中。我负责的模块就采用了此种实现方式，但比这个要求更加严格，在producer能够产生消息的源头就已经加了唯一索引，保证消息只能够产生一次。

    与消息中间件常见的使用方式，该方式主要增加了消息的记录以及定时任务重新发送消息机制，在业务逻辑中增加了对消息幂等性的校验等。

3.两阶段提交（2pc/xa）

    XA是X/Open组织提出的分布式事务的规范，XA规范定义了全局事务管理器(TM)规范和局部资源(RM)之间的接口。