1. 假设有个用宝币换礼品的业务?扣宝币和换礼品分别来自服务A, 服务B?怎么保证事务的一致性呢?
步骤:
1. 调用服务B, 礼品发至用户账户但是处于未生效状态。
2. 服务B,异步调用服务A扣减宝币。若当前A,B之间存在网络分区,用户宝币未减,虽有礼品但不生效。若A,B之间网络正常,但是扣减宝币时失败,依然出于宝币未减,虽有礼品但不生效。若调用A时,连接超时,异步状态无影响。
3. 正常扣减宝币后,异步调用服务B使礼品生效。遇上网络问题,调用不成功,可重发。
2. 分布式事务解决方案中2PC方案的核心逻辑是什么?有哪些产品是使用2PC原理实现的?
核心逻辑:引入一个协调者,协调者将统一掌控所有参与者的执行逻辑,并且指示参与者们是将结果提交还是将结果回滚。
产品:Seata, seata在开源之前,在阿里中已经广泛使用了,用来保证分布式事务的一致性,经历过双十一的考验
说明下Seata的逻辑,以及怎么将Seata融入springboot项目
参考博文:分布式事务对比 seata hmily byetcc easytransaction_chenshiying007的博客-CSDN博客_hmily seata
3. 使用2PC实现的产品的优缺点是什么?
4. TCC分布式事务解决方案的核心逻辑是什么?使用TCC原理实现的产品有哪些?
T: try, 预留业务资源,会对所有分支事务进行检查和预留业务资源
C: confirm, 确认执行业务操作,就只执行和提交
C: cancel,取消执行业务操作,执行操作失败是需要进行回滚操作
参考博文:分布式事物框架TCC-Transaction使用教程_varyall的博客-CSDN博客_tcc-transaction使用
5. TCC解决方案需要注意哪些问题?
6. 怎么解决TCC中,事务回滚先于事务执行的情况?
可以使用资源悬挂解决,回滚时记录如果不存在,可以先将记录插入。之后通过幂等性控制事务的执行。
7.TCC和2PC比较
2PC
很难用于并发较高以及子事务生命周期较长的分布式服务中
TCC
* 优点:2PC通常都是在跨库的DB层面,而TCC则在应用层面处理,需要通过业务逻辑实现,这种分布式事务的实现方式优势在于,可以让应用自己定义数据操作的粒度,使得降低锁冲突,提高吞吐量成为可能
* 而不足之处则在于对应用的侵入性非常强,业务逻辑的每个分支都需要实现Try,confirm,cancel三个操作。此外,其实现难度也比较大,需要按照网络状态,系统故障的不同失败原因实现不同的回滚策略
8. 在系统设计的时候怎么去选择CAP中的理论?
一般来说,绝大多数情况下,分布式系统中不是出于网络分区的状态,那需要保证数据的强一致性和系统可用性。那当出现网络分区的时候,会选择适当降低一致性的要求或者是系统可用性的要求。
参考资料:
13 | 正确性分级(中):多机无容灾有哪几种不同的一致性实现?-极客时间
防悬挂:处理异步的场景,为了防止,cancel执行,先于try执行的场景