学习打卡 (2023-01-31)

技术学习打卡 - 周志明的软件架构课
15 | 分布式事务之TCC与SAGA
https://time.geekbang.com/column/article/322301

I. TCC详解
1. 适用场景：强隔离事务场景
2. 对比 消息队列 适用场景：弱隔离的事务场景
3. TCC的流程
3.1) 向系统提交交易请求
3.2) 系统创建事务生成id，记录日志，各子系统检查冻结资源，通知下一步confirm or cancel
3.3) 系统检查所有子服务confirm，更新事务id在日志中状态，各子服务完成资源处理confirm
3.4) 如果全部子服务完成，则事务结束。否则，重复执行，尽最大努力交付
3.5) 如果第2步任意子服务cancel，更新日志状态cancel, 通知all子服务释放资源，执行cancel
3.6) 如果第5步全部完成，更新状态失败回滚完成，否则重复执行，尽最大努力交付
4. TCC优点：高性能
5. TCC的不足
5.1) 对编程代码的强侵入，后面的维护成本高
5.2) 通常借助于其他TCC中间件框架
5.3) 网银扣款长事务的情况-不适用，应用SAGA
II. Saga详解
1. 场景
1.1) 长时间的事务控制
1.2) 分布式异步事务
2. 构成
2.1) 将整个分布式事务 T 分解为 n 个子事务：T1，T2，…，Ti，…，Tn。每个原子性
2.2) 每一个子事务设计对应的补偿动作：C1，C2，…，Ci，…，Cn
3. Ti vs. Ci. 关系
3.1) Ti 与 Ci 都具备幂等性
3.2) Ti 与 Ci 满足交换律, 先执行哪个结果一样
3.3) Ci 必须能成功提交 否则重试或人工介入
4. 事务策略
4.1) 正向恢复（Forward Recovery）：如果 Ti 事务提交失败，则一直对 Ti 进行重试，直至成功为止（最大努力交付）
4.2) 反向恢复（Backward Recovery）：如果 Ti 事务提交失败，则一直执行 Ci 对 Ti 进行补偿，直至成功为止（最大努力交付）
5. Saga日志
5.1) 必须保证所有子事务都能够提交或者补偿
5.2) SAGA Log日志以保证系统恢复后可以追踪到子事务的执行情况
6. 两种模式
6.1) 事件/编排Choreography: 没有中央协调器(没有单点风险)，每个服务产生并聆听其他服务的事件，并决定是否应采取行动
6.2) 命令/协调orchestrator: 中央协调器负责集中处理事件的决策和业务逻辑排序