【分布式事务】怎么解决分布式场景下数据一致性问题
分布式事务的由来
拿充值订单举个栗子吧，假设：原本订单模块和账户模块是放在一起的，现在需要做服务拆分，拆分成订单服务，账户余额服务。原本收到充值回调后，可以将修改订单状态和扣减余额放在一个mysql事务中完成的，但是呢，因为服务拆分了，就面临着需要协调2个服务才能完成这个事务，所以我们怎么解决分布式场景下数据一致性问题呢？
本地事务、分布式事务
如果说本地事务是解决单个数据源上的数据操作的一致性问题的话，那么分布式事务则是为了解决跨越多个数据源上数据操作的一致性问题。
弱一致性
数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
最终一致性就属于弱一致性。
强一致性
系统中某个数据被更新后，后续任何对该数据的读取操作都能得到该更新后的值。在任意时刻，所有节点中的数据都是一致的。
2PC
XA是X/Open CAE Specification (Distributed Transaction Processing)模型中定义的TM（Transaction Manager）与RM（Resource Manager）之间进行通信的接口。
在XA规范中，数据库充当RM角色，应用需要充当TM的角色，即生成全局的txId，调用XAResource接口，把多个本地事务协调为全局统一的分布式事务。
二阶段提交是XA的标准实现。它将分布式事务的提交拆分为2个阶段：prepare和commit/rollback。
2PC模型中，在prepare阶段需要等待所有参与子事务的反馈，因此可能造成数据库资源锁定时间过长，不适合并发高以及子事务生命周长较长的业务场景 。两阶段提交这种解决方案属于牺牲了一部分可用性来换取的一致性。
优缺点：
优点：实现简单，使用数据库本身的事务实现
缺点：需要数据库本身支持事务
TCC（补偿事务）
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC模型是把锁的粒度完全交给业务处理。它分为三个阶段：
1、Try 阶段主要是对业务系统做检测及资源预留
2、Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
3、Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放
优缺点：
优点：可支持非事务数据库（redis），由业务自己编码实现
缺点：代码侵入性强
事务消息（半消息）
事务消息作为一种异步确保型事务， 将两个事务分支通过MQ进行异步解耦，事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：
1、事务发起方首先发送prepare消息到MQ。
2、在发送prepare消息成功后执行本地事务。
3、根据本地事务执行结果返回commit或者是rollback。
4、如果消息是rollback，MQ将删除该prepare消息不进行下发，如果是commit消息，MQ将会把这个消息发送给consumer端。
5、如果执行本地事务过程中，执行端挂掉，或者超时，MQ将会不停的询问其同组的其它producer来获取状态。
Consumer端的消费成功机制有MQ保证。