传统分布式事务
我们先来看下第一部分，传统使用本地事务和分布式事务保证一致性。
传统单机应用一般都会使用一个关系型数据库，好处是应用可以使用ACID。为保证一致性我们只需要：开始一个事务，改变（插入，删除，更新）很多行，然后提交事务（如果有异常时回滚事务）。更进一步，借助开发平台中的数据访问技术和框架（如 Spring），我们需要做的事情更少，只需要关注数据本身的改变。
随着组织规模不断扩大，业务量不断增长，单机应用和数据库已经不足以支持庞大的业务量和数据量，这个时候需要对应用和数据库进行拆分，这就出现了一个应用需要同时访问两个或两个以上的数据库情况。开始我们用分布式事务来保证一致性，也就是我们常说的两阶段提交协议（2PC）。
本地事务和分布式事务现在已经非常成熟，相关介绍很丰富，此处不再讨论。我们下面来谈谈为什么分布式事务不适用于微服务架构。
首先，对于微服务架构来说，数据访问变得更加复杂，这是因为数据都是微服务私有的，唯一可访问的方式就是通过 API。这种打包数据访问方式使得微服务之间松耦合，并且彼此之间独立，更容易进行性能扩展。其次，不同的微服务经常使用不同的数据库。应用会产生各种不同类型的数据，关系型数据库并不一定是最佳选择。例如，某个产生和查询字符串的应用采用 Elasticsearch 的字符搜索引擎；某个产生社交图片数据的应用可以采用图数据库，例如Neo4j。基于微服务的应用一般都使用 SQL 和 NoSQL 结合的模式。但是这些非关系型数据大多数并不支持 2PC。可见在微服务架构中已经不能选择分布式事务了。
最终一致性原则
依据 CAP 理论，必须在可用性（availability）和一致性（consistency）之间做出选择。如果选择提供一致性需要付出在满足一致性之前阻塞其他并发访问的代价。这可能持续一个不确定的时间，尤其是在系统已经表现出高延迟时或者网络故障导致失去连接时。依据目前的成功经验，可用性一般是更好的选择，但是在服务和数据库之间维护数据一致性是非常根本的需求，微服务架构中应选择满足最终一致性。最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。当然选择了最终一致性，就要保证到最终的这段时间要在用户可接受的范围之内。那么我们怎么实现最终一致性呢？从一致性的本质来看，是要保证在一个业务逻辑中包含的服务要么都成功，要么都失败。那我们怎么选择方向呢？保证成功还是保证失败呢？
我们说业务模式决定了我们的选择。实现最终一致性有三种模式：可靠事件模式、业务补偿模式、TCC 模式。
转载于:https://blog.51cto.com/17099933344/2054640
