分布式事务
:
就是指事务的参与者、支持事务的服务器、资源服务器以及事务
管理器分别位于不同的分布式系统的不同节点之上。简单来说,分布式事务指
的就是分布式系统中的事务,它的存在就是为了保证不同数据库节点的数据一
致性。
聊到分布式事务,大家记得这两个理论哈:
CAP
理论 和
BASE
理论
分布式事务的几种解决方案:
- 2PC(二阶段提交)方案、3PC
- TCC(Try、Confirm、Cancel)
- 本地消息表
- 最大努力通知
- seata
2PC(
二阶段提交
)
方案
2PC
,即两阶段提交,它将分布式事务的提交拆分为
2
个阶段:
prepare
和
commit/rollback
,即准备阶段和提交执行阶段。在
prepare
准备阶段需要等待
所有参与子事务的反馈,因此可能造成数据库资源锁定时间过长,不适合并发
高以及子事务生命周长较长的业务场景。并且协调者宕机,所有的参与者都收
不到提交或回滚指令。
3PC
两阶段提交分别是:
CanCommit
,
PreCommit
和
doCommit
,这里不再详述。
3PC
利用超时机制解决了
2PC
的同步阻塞问题,避免资源被永久锁定,进一步加强
了整个事务过程的可靠性。但是
3PC
同样无法应对类似的宕机问题,只不过出
现多数据源中数据不一致问题的概率更小。
TCC
TCC
采用了补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应
的确认和补偿(撤销)操作。它分为三个阶段:
Try-Confirm-Cancel
try
阶段:尝试去执行,完成所有业务的一致性检查,预留必须的业务资源。
Confirm
阶段:该阶段对业务进行确认提交,不做任何检查,因为
try
阶段已经检
查过了,默认
Confirm
阶段是不会出错的。
Cancel
阶段:若业务执行失败,则进入该阶段,它会释放
try
阶段占用的所有业
务资源,并回滚
Confirm
阶段执行的所有操作。
TCC
方案让应用可以自定义数据库操作的粒度,降低了锁冲突,可以提升性能。
但是应用侵入性强,
try
、
confirm
、
cancel
三个阶段都需要业务逻辑实现。
本地消息表
ebay
最初提出本地消息表这个方案,来解决分布式事务问题。业界目前使用
这种方案是比较多的,它的核心思想就是将分布式事务拆分成本地事务进行处
理。可以看一下基本的实现流程图:
![](https://i-blog.csdnimg.cn/blog_migrate/f265c877a744b144293e793b4d45e2f7.png)
最大努力通知
最大努力通知方案的目标,就是发起通知方通过一定的机制,最大努力将业务
处理结果通知到接收方。
seata
Saga
模式是
Seata
提供的长事务解决方案。核心思想是将长事务拆分为多个
本地短事务,由
Saga
事务协调器协调,如果正常结束那就正常完成,如果某
个步骤失败,则根据相反顺序一次调用补偿操作。
Saga
的并发度高,但是一致性弱,对于转账,可能发生用户已扣款,最后转
账又失败的情况