分布式事务

什么是分布式事务？

简单的说，就是一次大操作由不同小操作组成，这些小操作分布在不同服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败.

两阶段提交

两阶段提交简称2PC(two phase commitment)

基本概念

• TM(Transaction Manager) 事务管理器
• RM(Resource Manager) 资源管理器

两阶段提交:

• 在第一阶段, 资源管理器向事务管理器汇报各自事务的状态;
• 在第二阶段, 事务管理器根据资源管理器汇报的状态来来确定是回滚还是提交;

注: 两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题.

两阶段提交协议是基于XA规范, 阻塞, 属于刚性事务

数据库实现(XA, MySQL和Oracle都支持)

xa_start, xa_end, xa_prepare, xa_commit, xa_rollback

TCC

基本原理

TCC(Try Confirm Cancel), 是2PC的一种改进

事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。

优缺点

TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。 当然TCC方案也有不足之处，集中表现在以下两个方面：

• 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
• 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。

基于消息的最终一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。

消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。

阿里的GTS

Fescar（Fast & EaSy Commit And Rollback), 升级后为: Seata(Simple Extensible Autonomous Transaction Architecture)

seata 工作原理

下面是来自于seata的工作原理图

• Transaction Coordinator(TC): 用来协调全局事务和各个分支事务的状态, 驱动全局事务和各个分支事务的回滚或提交
• Transaction Manager(TM): 定义了事务的范围(一般是业务层), 用来开启/提交/回滚一个整体事务
• Resource Manager(RM): 管理分支事务, 与TC进行协调注册分支事务并且汇报分支事务的状态, 驱动分支事务的提交或回滚

seata管理分布式事务的生命周期

1. TM向TC请求开启一个新的全局事务, TC生成一个代表该全局事务的XID
2. XID在整个microservice的整个调用链中都可见
3. RM把本地事务向TC注册为XID全局事务的一个分支
4. TM向TC请求XID全局事务的提交或回滚
5. TC驱动所有XID全局事务的提交或回滚

数据一致性

数据不一致产生的原因

• 不同的DB(用户有UserDB, 商品有Product DB)
• DB和缓存(商品有Product DB 和 Product Cache)

问题1: 如果把下单操作和把下单消息放到MQ的操作放到一个try-catch块中

try {
  // 下单
  orderService.createOrder();
  // 发送消息到MQ
  msgClient.sendMsg(orderId);
} catch (Exception e) {
}

发送消息是网络操作, 网络操作一般会有3中结果: success, fail, timeout. Success 和 fail都相对好处理, 但是timeout是不知道消息发送成功还是失败的.所以这种操作是不合理的.

解决方法: 一般会先把下单成功的消息放入DB中, 然后从DB中取数据放入MQ

分布式缓存和数据库的一致性4步骤:

• 先更新数据库, 然后delete缓存
• 延时双删
• 设置缓存失效时间
• 记录日志, 脚本定期修正

柔性分布式事务(saga)

Saga模式是现实中可行的方案，采用事务补偿机制。每个本地事务都存储一个副本，如果出现失败，则利用补偿机制回滚。

TCC模型和saga模型

TCC(Try, Confirm, Cancel), 以A向B账户转账为例, 分为汇款服务和收款服务

saga-汇款服务:

• Try:检查A账户的有效性, 账户状态,是否冻结等, 账户余额是否充足从A账户中扣减500元, 并将状态置为转账中预留扣减资源, 将A往B账户转账这个事件存入MQ(或DB)中
• Confirm:不做任何操作
• Cancel:A账户增加500元从MQ(或DB)中,释放扣减资源

saga-收款服务:

• Try:检查B账户的有效性
• Confirm:读MQ(或DB), B账户增加500元从MQ(或DB)释放扣减资源
• Cancel:不做任何操作

saga模型:

把一个长事务拆分成多个短事务(本地事务), 每个事务都有对应的执行模块和补偿模块(对应TCC中的Confirm 和 Cancel)

• 当任意一个本地事务出错, 就根据本地事务的补偿方法恢复之前的事务, 达到事务的最终一致性.
• 当最后一个本地事务失败时, 整个事务就失败, 不需要补偿. 所以针对N个本地事务, 只有对应N - 1个事务补偿

saga vs TCC

区别在于TCC多了一个Try(预操作), 每次都会预扣减资源. saga虽然也有Try操作, 但是只是做一些检测操作

saga 时序图

TCC时序图

刚性事务vs 柔性事务

redis做分布式锁的问题

SET lock_key random_value NX PX 5000

• 锁没有办法严格保证唯一, 如使用master-slave模式, 当线程A通过setnx(orderId,...)拿到锁, 执行操作, 此时master挂掉, slave变为master, 原有的锁记录丢失. 线程B这时可以拿到锁, 就出现问题
• Redis锁存在租约问题, 如果操作执行时间超过了锁的有效期, 那么线程B同样会拿到锁

注: redis从本质上说是AP模型, 只保证可用. 如果需要用分布式锁, 必须是CP模型, 需要保证一致性.etcd可以保证.

分布式缓存的高可用

缓存不可用, 查询数据库,

做好评估: 缓存宕机, 评估数据库压力