1、分布式事务
tcc、柔性事务
2、最终一致性
可以做的事情:
工具化实现()
常用方案总结(强一致、弱一致、最终一致)
常用场景总结
数据库分库(目前主要场景)
不同中间件(mq、数据库)
不同的应用()
实现原理
强一致:
2pc:投票、决定
问题:
单点故障:事务管理器出现故障,整个系统不可用
数据不一致:在阶段2事务管理器只成功发送了部分commit信息。
响应时间较长(并发效率低):当事务管理器发送commit后,并且只有一个参与者收到commit,那么当该参与者与事务管理器同时宕机之后,新选举的事务管理器无法确认该消息是否成功。
基于2PC 的Percolator
优点:
1、事务管理器会记录操作日志,为多节点转移故障做好准备。
2、提交阶段只和一个参与者交互,保证原子性。
3pc:
新增了CanCommit和超时机制。如果一段时间内没有收到协调者的commit请求,则自动commit。解决了单点问题,但是性能问题和不一致问题任然没有解决
tcc:补偿机制
解决了协调者单点问题,有主业务方发起并完成这个业务活动。
同步阻塞:引入超市,超时后补偿,并且不会锁定整个资源,将资源转换为业务逻辑形式。
数据一致性,有了补偿机制,由业务活动管理器控制一致性
缺点:TCC就是通过业务代码变相的实现了2PC,不同的业务场景逻辑不完全一样。并且很大程度上增加了业务代码的复杂度。因此,这种模式不能很好的被复用。
本地消息表
一、将多方数据写入同一个数据库,然后不断轮询待处理消息。
二、1、消息生产方,单独建一个消息表,并记录消息发送状态。消息表和业务表要在一个事务提交。然后消息经过MQ发送到消费方,如果消息发送失败会进行重试。
2、消息消费方,需要处理消息,并完成自身业务逻辑。如果上面的业务失败,可以给生产方发送一个业务补偿消息,通知生产方进行回滚操作。
3、如果本地事务成功,表明处理成功。如果失败,重试执行。
4、生产和消费方会定时扫描消息表,把还没处理完的消息或者失败的消息再发送一遍
消息事务
依赖消息中间件对分布式事务进行分拆,强依赖中间件。目前支持方案 RockerMQ
最大努力通知(最终一致性要求低)
1、系统A本地事务执行完,发送MQ
2、专门消费服务,调用系统B
3、执行失败进行重试N次
Sagas事务模型长时间运行的事务
将长事务拆分为多个本地短事务,由Saga事务协调器协调,如果正常结束那就正常完成。如果某个步骤失败,则根据相反顺序依次调用补偿操作。