1、分布式事务

tcc、柔性事务

2、最终一致性

可以做的事情：

、工具化实现（目前jed有tcc实现，但是默认是关闭的，验证jed tcc可行性）

常用方案总结（强一致、弱一致、最终一致）

常用场景总结

数据库分库（目前主要场景）

不同中间件（mq、数据库）

不同的应用（）

目前实现原理

强一致：

2pc：投票、决定

问题：

单点故障，事务管理器出现故障，整个系统不可用

数据不一致：在阶段2事务管理器只成功发送了部分commit信息。

响应时间较长：当事务管理器发送commit后，并且只有一个参与者收到commit，那么当该参与者与事务管理器同时宕机之后，新选举的事务管理器无法确认该消息是否成功。

3pc：

新增了CanCommit和超时机制。如果一段时间内没有收到协调者的commit请求，则自动commit。解决了单点问题，但是性能问题和不一致问题任然没有解决

tcc：补偿机制

解决了协调者单点问题，有主业务方发起并完成这个业务活动。

同步阻塞：引入超市，超时后补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式。

数据一致性，有了补偿机制，由业务活动管理器控制一致性

缺点：TCC就是通过业务代码变相的实现了2PC，不同的业务场景逻辑不完全一样。并且很大程度上增加了业务代码的复杂度。因此，这种模式不能很好的被复用。

本地消息表

一、将多方数据写入同一个数据库，然后不断轮询待处理消息。

二、1、消息生产方，单独建一个消息表，并记录消息发送状态。消息表和业务表要在一个事务提交。然后消息经过MQ发送到消费方，如果消息发送失败会进行重试。

2、消息消费方，需要处理消息，并完成自身业务逻辑。如果上面的业务失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚操作。

3、如果本地事务成功，表明处理成功。如果失败，重试执行。

4、生产和消费方会定时扫描消息表，把还没处理完的消息或者失败的消息再发送一遍

消息事务

依赖消息中间件对分布式事务进行分拆，强依赖中间件。目前支持方案 RockerMQ

最大努力通知（最终一致性要求低）

1、系统A本地事务执行完，发送MQ

2、专门消费服务，调用系统B

3、执行失败进行重试N次

Sagas事务模型长时间运行的事务

将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成。如果某个步骤失败，则根据相反顺序依次调用补偿操作。