分布式事务

一、背景

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两阶段方式，和单机事务一样，异常恢复系统负责根据事务日志恢复异常