不懂分布式事务，别说你懂微服务！

最近学习了一下微服务下数据一致性的特点，总结了下目前的保障微服务下数据一致性的几种实现方式如下，以备后查。此篇文章旨在给大家一个基于微服务的数据一致性实现的大概介绍，并未深入展开，具体的实现方式本人也在继续学习中，如有错误，欢迎大家拍砖。

1. 传统应用的事务管理

1.1 本地事务

再介绍微服务下的数据一致性之前，先简单地介绍一下事务的背景。传统单机应用使用一个RDBMS作为数据源。应用开启事务，进行CRUD，提交或回滚事务，统统发生在本地事务中，由资源管理器（RM）直接提供事务支持。数据的一致性在一个本地事务中得到保证。

1.2 分布式事务

1.2.1 两阶段提交（2PC）

当应用逐渐扩展，出现一个应用使用多个数据源的情况，这个时候本地事务已经无法满足数据一致性的要求。由于多个数据源的同时访问，事务需要跨多个数据源管理，分布式事务应运而生。其中最流行的就是两阶段提交（2PC），分布式事务由事务管理器（TM）统一管理。

两阶段提交分为准备阶段和提交阶段。

两阶段提交-commit

两阶段提交-rollback

然而两阶段提交也不能完全保证数据一致性问题，并且有同步阻塞的问题，所以其优化版本三阶段提交（3PC）被发明了出来。

1.2.2 三阶段提交（3PC）

三阶段提交

然而3PC也只能保证绝大多数情况下的数据一致性。

具体分布式事务2PC和3PC的详细介绍请见 关于分布式事务、两阶段提交协议、三阶提交协议 。分布式事务不是本文的重点，故不展开。

2. 微服务下的事务管理

那么，分布式事务2PC或者3PC是否适合于微服务下的事务管理呢？答案是否定的，原因有三点：

1. 由于微服务间无法直接进行数据访问，微服务间互相调用通常通过RPC（dubbo）或Http API（SpringCloud）进行，所以已经无法使用TM统一管理微服务的RM。
2. 不同的微服务使用的数据源类型可能完全不同，如果微服务使用了NoSQL之类不支持事务的数据库，则事务根本无从谈起。
3. 即使微服务使用的数据源都支持事务，那么如果使用一个大事务将许多微服务的事务管理起来，这个大事务维持的时间，将比本地事务长几个数量级。如此长时间的事务及跨服务的事务，将为产生很多锁及数据不可用，严重影响系统性能。

由此可见，传统的分布式事务已经无法满足微服务架构下的事务管理需求。那么，既然无法满足传统的ACID事务，在微服务下的事务管理必然要遵循新的法则－－BASE理论。

BASE理论由eBay的架构师Dan Pritchett提出，BASE理论是对CAP理论的延