分布式事务

一、背景

1、分布式架构中，由于后台服务器数量不再是单机，数据库采用分库分表策略，数据库分布在不同的多台服务器上，在单机背景下对数据库的操作ACID已不再适用于分布式系统。在分布式架构中如何保证事务的原子性、一致性、隔离性、持久性成为技术的突破点。
2、分布式事务业界还没有开源的产品，主流公司各自研发自己的分布式事务框架。

二、解决方案 – CAP理论

当我们的单个数据库的性能产生瓶颈的时候，我们可能会对数据库进行分区，这里所说的分区指的是物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID几乎是很难达到，或者即使能达到那么效率和性能会大幅下降，最为关键的是再很难扩展新的分区了，这个时候如果再追求集群的ACID会导致我们的系统变得很差，这时我们就需要引入一个新的理论原则来适应这种集群的情况，就是 CAP 原则或者叫CAP定理

2.1、CAP三大特性

• 一致性(Consistency) ： 每个操作在分区数据库数据保证最终数据一致性（同时生效）
• 可用性(Availability) ： 每个操作都必须以可预期的响应结束
• 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成

2.2、 两阶段提交 – 2PC

• 第一阶段：预发阶段
• 第二阶段：提交/回滚阶段
  
  说明：分布式事务先对多台不同的服务器预发操作，各台服务器收到操作指令后回复是否成功，如果成功，则提交事务，否则，回滚事务。

2.3、TCC(try + confirm + cancle)

• try：主要对不同服务器检测和资源的预留
• confirm：提交阶段
• cancle：回滚阶段
  说明：分布式事务先对不同的服务器进行检测，资源预留，之后尝试事务操作，如果成功则提交，否则，回滚事务

2.4、基于消息中间件完成CAP

说明：消息发送者负责发送消息到消息中心，消息中心负责向消息接受者（后台服务器）发送消息，实现分布式事务，如果发送失败，消息中心会定期发送，消费直到成功，保证事务的一致性和可用性

2.5、2PC与TCC、基于消息中间件的区别

• 2PC两阶段提交追求保证事务的一致性，但是可用性降低，不适用与高并发的场景
• TCC对在2PC两阶段提交基础上对一致性和可用性做了平衡
• 基于消息中间件分布式事务是CAP的很好实现者

2.6 个人设计

说明：分布式事务采用2PC两阶段方式，和单机事务一样，异常恢复系统负责根据事务日志恢复异常