分布式事务,TCC, SAGA, 柔性事务, 刚性事务详解
什么是分布式事务？
简单的说，就是一次大操作由不同小操作组成，这些小操作分布在不同服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败.
两阶段提交
两阶段提交简称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™: 定义了事务的范围(一般是业务层), 用来开启/提交/回滚一个整体事务
- Resource Manager(RM): 管理分支事务, 与TC进行协调注册分支事务并且汇报分支事务的状态, 驱动分支事务的提交或回滚
seata管理分布式事务的生命周期
- TM向TC请求开启一个新的全局事务, TC生成一个代表该全局事务的XID
- XID在整个microservice的整个调用链中都可见
- RM把本地事务向TC注册为XID全局事务的一个分支
- TM向TC请求XID全局事务的提交或回滚
- 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 柔性事务
| 刚性事务(XA模型) | 柔性事务 | |
|---|---|---|
| 实际项目中有无应用场景 | 无 | 有 |
| 回滚 | 支持 | 通过补偿支持 |
| 一致性 | 强一致性 | 最终一致性 |
| 隔离性 | 原生支持 | 实现资源锁定接口(如信用卡预授权) |
| 并发性能 | 低, 严重衰退(锁定资源时间太久) | 略微衰退 |
| 适合场景 | 短事务,并发较低 | 长事务, 高并发 |
redis做分布式锁的问题
SET lock_key random_value NX PX 5000
- 锁没有办法严格保证唯一, 如使用master-slave模式, 当线程A通过setnx(orderId,…)拿到锁, 执行操作, 此时master挂掉, slave变为master, 原有的锁记录丢失. 线程B这时可以拿到锁, 就出现问题
- Redis锁存在租约问题, 如果操作执行时间超过了锁的有效期, 那么线程B同样会拿到锁
注: redis从本质上说是AP模型, 只保证可用. 如果需要用分布式锁, 必须是CP模型, 需要保证一致性.etcd可以保证.
分布式缓存的高可用
缓存不可用, 查询数据库,
做好评估: 缓存宕机, 评估数据库压力
持续更新(注)
该篇blog并不代表该知识点的所有内容, 在今后的工作学习中, 持续更新! 如对blog中的观点有异议/建议,请发送email至: [email protected], 感谢您的阅读.