常见的分布式事务场景
分布式事务其实就在我们身边，你一直在用，但是你却一直不注意它。
转账
扣你账户的余额，增加别人账户余额，如果只扣了你的，别人没增加这是失败；如果没扣你的钱别人也增加了那银行的赔钱。
下订单/扣库存
电商系统中这是很常见的一个场景，用户下单成功了，店家没收到单，不发货；用户取消了订单，但是店家却看到了订单，发了货。
分库分表场景
当我们的数据量大了之后，我们可能会部署很多独立的数据库，但是你的一个逻辑可能会同时操作很多个数据库的表，这时候该如何保证所有的操作要么成功，要么失败。
分布式系统调用问题
微服务的拆分让各个系统各司其职，但是带来的也有很多痛苦，一个操作可能会伴随很多的外部请求，如果某一个外部系统挂掉了，之前操作已完成的这些是否需要回滚。
针对上面这些问题，我们前面学过的数据库4大特性：ACID 似乎在这里想要达到就变得很困难，单机情况下你还可以通过锁和日志机制来控制数据，在分布式场景又该如何实现呢？在不同的分布式应用架构下，实现一个分布式事务要考虑的问题并不完全一样，比如对多资源的协调、事务的跨服务传播等，实现机制也是复杂多变。尽管有这么多工程细节需要考虑，但分布式事务最核心的还是其 ACID 特性，只是这种 ACID 变换了场景。
分布式理论
CAP 定理
传统的 ACID 模型肯定无法解决分布式环境下的挑战，基于此加州大学伯克利分校 Eric Brewer教授提出 CAP 定理，他指出 现代 WEB 服务无法同时满足以下 3 个属性：
- 一致性(Consistency) ： 所有的客户端都能返回最新的操作。
- 可用性(Availability) ： 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。
- 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用，操作依然可以完成。
关于一致性的理解后面分出来三个方向：
- 强一致：任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。
- 弱一致：数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
- 最终一致：不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。
关于一致性的理解不同，后面对于 CAP 理论的实现就有所不同。
另外 Eric Brewer教授指出现代 WEB 服务无法同时满足这 3 个属性，说的是无法同时满足，那这是为什么呢？
如果在某个分布式系统中无副本，那么必然满足强一致性，同时也满足可用性，但是如果这个数据宕机了，那么可用性就得不到保证。
如果一个系统满足 AP，那么一致性又得不到保证。所以 CAP 原则的精髓就是要么 AP，要么 CP，要么 AC，但是不存在 CAP。
BASE 定理
基于前面提到的 CAP，反正我们都无法同时满足CAP，设计系统的最高目的就是让他跑下去不出错，那么是不是可以不要求强一致性，最终让他一致即可。所以后面又提出来了 BASE 定理：
- Basically Available（基本可用）
- Soft state（软状态）
- Eventually consistent（最终一致性）
基于现在大型分布式系统的复杂性，我们无法保证服务永远达到999，那么是否可以取舍，核心服务达到999，非核心服务允许挂为了保全核心服务。另外在非核心服务 down 机过程中允许系统暂时出现不一致但是这个不一致并不影响系统的核心功能使用。
最终系统恢复，所有服务一起修复数据，最终达到一致的状态。
业内通常把严格遵循 ACID 的事务称为刚性事务，而基于 BASE 思想实现的事务称为柔性事务。柔性事务并不是完全放弃了 ACID，仅仅是放宽了一致性要求：事务完成后的一致性严格遵循，事务中的一致性可适当放宽。
常见的分布式事务实现方案
分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务：通常无业务改造，强一致性，原生支持回滚/隔离性，低并发，适合短事务。柔性事务：有业务改造，最终一致性，实现补偿接口，实现资源锁定接口，高并发，适合长事务。
- 刚性事务：XA 协议（2PC、JTA、JTS）、3PC
- 柔型事务：TCC/FMT、Saga（状态机模式、Aop模式）、本地事务消息、消息事务（半消息）、最多努力通知型事务
两阶段提交(XA)
与本地事务一样，分布式事务场景下也可以采用两阶段提交的方案来实现。XA 的全称是 eXtended Architecture，它是一个分布式事务协议，通过二阶段提交协议保证
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
