一致性这个词重载的很厉害，在不同的语境和上下文中，它其实代表着不同的东西：
- 在事务的上下文中，比如ACID里的C，指的就是通常的一致性（Consistency）
- 在集群环境中，主从复制，如ZK（Paxos）、Redis（Raft）等强一致性算法的影子
- 此外，“一致性哈希”，“最终一致性”这些名词里的“一致性”也有不同的涵义。
参考：知乎。
总结：这里事务的一致性和强一致性算法根本不是一个东西，网上我们看到很多帖子介绍2pc、3pc解决分布式事务的算法时，到最后都会加，他们无法保证强一致性，强一致性还得Paxos，其实这样说法根本就是错的，他们解决的根本不是同一个领域的问题（当然，它们两可以搭配使用，比如2pc协调者可以使用Paxos选出）。下面我们来深入分析下。
CAP
首先无论是分布式系统中的事物问题（不同数据节点 或者 不同服务节点），还是集群中的数据一致性（多个相同数据节点 或者 多个相同服务节点）。他们都避不开CAP理论，CAP的基础就在于我们的节点在P不同网络分区内。只能从C一致性和A可用性中选取一个。如下面的情况：
1.分布式系统中的事物问题：A处理成功 B处理失败（无论是网络问题还是自身宕机）
2.集群中的数据一致性：C写成功，C，同步失败（无论是网络问题还是自身宕机）
这两种都是遵循CAP理论的，但是他们在C、A中的选取走向了两个方向。
在分布式系统中的事物问题中，我们无法选择强一致性因为这会使得使得服务节点B不可用，即使服务节点B可能也是集群，但B的集群共用底层数据节点，一个或者多个服务节点B没有区别（这里可自行琢磨下），服务节点B不可用会导致我们整个业务不可用，如：A是下单，B位减库存。不可能因为B出现了一笔订单没有扣减，导致不就行扣减其他商品库存。但如果我们选择了可用性，货物就将出现超卖问题，所以此时出现了另一个理论BASE理论用于解决分布式事务数据一致性，我们后面分析。
在集群中的数据一致性问题中，在这种情况下，数据节点C、C，数据是相同的。我们可以选择使数据节点C，不可用，只有C来提供数据服务，等到数据节点C，重启或者网络恢复。我们将数据节点C的数据同步给数据节点C，，而我们经常听到的zk的Paxos、redis哨兵的Raft就是使C，不可用、给C，恢复数据用的一种算法，所以很多人为了把它和分布式事务一致性区分开，更喜欢叫它共识算法，保证各个数据节点数据是共识的，但这种一直并不保证他对应的业务层的分布式事务操作的数据是一致的，举个例子 当存储 1，2之后，特殊情况下，会导致所有数据节点存储都是1而不是2，这样在数据层面数据是共识的，但是业务上可能导致了事务的不一致。有机会给大家举例说明下。
BASE
上面我们讲到在分布式事务一致性的情况下，我们希望既保证可用性又使得不一致性的危害降到最低。就有BASE理论，即
- 基本可用（Basically Available）
- 软状态（Soft State）
- 最终一致性（Eventually Consistent）
在分布式事务一致性算法中2PC、3PC遵循了基本可用、最终一致性。因为当业务节点B对数据库操作失败时，当然可以直接理解为数据节点的事务，要能和上面集群数据节点区分，业务节点B对应的数据节点会去协调者查询执行状态来提交或者回滚，这里提一嘴：2PC在第二次提交时节点和协调者同时挂掉会导致当前事务状态不可知，所以有了3PC，这个也放到后面文章讲。
TCC，不同2PC、3PC数据节点事务一致性，他是业务节点的层面的。BASE理论的大成者通过Try节点修改成软状态状态，再通过confrim或者cancel来处理事务。confrim或者cancel一步出现异常，他提供日志机制进行重试或告警达到基本可用、最终一致性
再提一种业务节点事务一致性方案SAGA，它是通过 记录指令 与 反向指令，比如购买指令，购买失败后有退款指令。我们将指令之间逻辑关系配置好。但saga有个致命问题就是，他既没有tcc的软状态、有没有2pc、3pc的数据库事务（redo log），会导致数据没有隔离性。导致其他业务读取到脏数据。还是举个例子吧????， 小明向xx公司买东西， ，A：小明-100 B：xx +100 C：商品出库，但是出库操作C失败了，我们要执行反相指令，xx -100， 小明+100，可是这个时候xx拿去100进货了，他没有100去减了。所以saga还是在一致性要求不那么高的时候用，高的话还是TCC吧。
不知道大家是否能够理解明白，我再画一张图吧有助于理解
try 阶段 ： service B 冻结100元， service C 库存冻结 1。
confirm 阶段： service B减 100， service C 库存减 1。
这里无论是Try阶段service B、 service C两步冻结数据操作
还是 C阶段service B、 service C两步数据减操作
都可以对应2PC，3PC。
当时业务层用TCC保证了分布式事务一致性的话，数据层可以不用2pc或者3pc了。
布式事务一致性（2PC、3PC、TCC）之间的关系 强一致性算法Paxos
他们两者本质不是一个层面的东西，但是可以一起搭配使用的，比如2pc/3pc的协调者，为了防止单点问题，提高可用性，可以使用协调者集群，但是集群之间使用Paxos来保证协调者之间数据的共识