分布式事务

seata 分布式事务简介 分布式事务产生的根本原因 组成业务逻辑的一组操作使用的数据库连接不是同一个 CAP理论(布鲁尔定理) 分布式系统中无法同时满足CAP Consistency 一致性 一致性指all nodes see the same data at the same time，即所有节点在同一时间的数据完全一致。

分布式事务 分布式事务模式总结 方案 简介 事务分类 一致性 总结 实现 / 产品 / 框架 两阶段提交（2PC） 二阶段分别指的是准备和提交两个阶段 数据库层面 强一致性 锁资源 - 阻塞 - 效率低 Seata 三阶段提交（3PC） 准备阶段、预提交阶段和提交阶段 数据库层面 强一致性 引入一个阶段也多一个交互，因此性能会差一些 TCC（补偿事务） TCC 指的是 Try - Confirm - Cancel 业务层面 最终一致性 执行效率高，基于 TCC 实现分布式事务，会将原来只需要一个接口就可以实现的逻辑拆分为 Try、Confirm、Cancel 三个接口，所以代码实现复杂度相对较高。 Seata Saga 模式 Saga 是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务 业务层面 最终一致性 一阶段提交本地事务，无锁，高性能 事件驱动架构，参与者可异步执行，高吞吐 补偿服务易于实现不保证隔离性 Seata 最大努力通知 柔性事务的思想：尽力最大的努力达成事务的最终一致；直接传递消息消费，要是成功则成功，要是失败则多重试几次，还是不成功就算了 业务层面 最终一致性 适用于对时间不敏感的业务；最大努力通知事务方案既没有使用本地表扫描，也未使用可靠消息机制,一般会提供主动查询接口 本地消息表 本地消息表其实就是利用了 各系统本地的事务来实现分布式事务 业务层面 最终一致性 此方案的核心是将需要分布式处理的任务通过消息日志表的方式来异步执行，执行成功后修改消息的状态；此外另起一个线程，不断轮询本地消息表中未处理成功的消息再次发起调用。与 tcc 相比，实现方式较为简单，开发成本低。缺点： 事务业务与消息发送业务耦合 、业务数据与消息表要在一起 MQ 消息事务 RocketMQ 事务消息的功能 业务层面 最终一致性 该方案与本地消息最大的不同是去掉了本地消息表，由 MQ 来实现消息的可靠性传递，确认消息一定被消费。业务相对简单，不需要编写三个阶段业务 缺点：代码侵入,还需要编写回查接口， 依赖于 MQ 的可靠性.