ACID 特性是 CAP 中一致性的边界，可以称作最强的一致性，如果分布式系统中实现了一致性，必然会影响到可用性。如果一个节点失败，这个分布式事务的执行都是失败的。
绝大数场景中，对一致性要求没那么高，并不需要保证强一致性，短暂的不一致也能接收，最后能保证数据是正确的就OK。也就是说我们可以用最终一致性方案来保证数据的一致性。
另外要提到的就是 TCC 协议（三阶段提交协议），他是针对二阶段提交中的：协调者故障，参与者长期锁定资源的痛点而出的协议。引入了询问阶段和超时机制，减少资源被长时间锁定。但是需要更多的消息进行协商，增加了系统负载和响应延迟，所以三阶段提交协议很少被使用。
三、太极的柔 3.1 BASE 的柔讲了太极的刚，下面来讲太极的柔。谈到分布式事务的柔，一定会提到 BASE 理论，俗称柔性事务。BASE 理论是 CAP 理论中 AP 的扩展。大部分互联网分布式系统都强调可用性，都会考虑引入 BASE 支持。这个理论非常非常重要，我要告诉你的是，掌握了这个理论，设计出符合自己业务的分布式架构也会变得容易很多，而不是摸不着头脑。
BASE 的核心：基本可用 BA（Basically Available）、软状态 S（Soft state）、最终一致性 E（Eventually consistent）。
那为什么叫它柔性事务？其实它和 ACID 是相对的，不需要保证强一致性，比如一根橡皮筋被拉弯了，你放开橡皮筋后，它就会自行恢复，这个就是橡皮筋柔性的一面。
3.2 BASE 和太极拳有什么关系太极拳每一招都不是直直的打出去的，每一招都讲求圆滑、画弧线，看起来软绵绵的，其实是柔中带刚。每一招的最后一下都是非常刚硬的抖动一下（这效果我用文字实在描述不出来，大家去看电视吧）。这最后一下就可以看成是刚的一面，也就是最终一致性。
怎么理解基本可用？重点是在这个基本，这个理论并没有告诉我们怎么定义基本，这是一个模糊的概念。其实就是要柔到什么程度。
在分布式系统中，我们可以把基本可用理解为保证核心功能可用，允许损失部分功能的可用性。基本可用可以用四种方案来实现。
流量削峰：比如多个秒杀场次，某东的 8 点秒杀场，12 点的秒杀场。
延迟响应：比如双 11 期间某商城创建的订单，会提示客户订单正在创建中，可能需要等个十几秒。
体验降级：比如某次比赛活动，有大量用户进活动页查看图片，这个时候，大量图片因为网络超时而无法显示，这个时候就可以考虑替换原有图片，返回清晰度没有那么高或图片比较小的图片。
过载保护：比如我们常用的消息队列占满了，可以考虑丢弃后来的请求，或清除队列中的一些请求，保护系统不过载，但这都需要结合自身的业务场景来设计。
3.4 最终一致性最终一致性：系统中的所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。最终可以理解为一个短暂的延迟。
最终一致性在非常多的互联网业务中采用。但是跟钱打交道或金融系统会采用强一致性或事务。
前面提到了 ACID 的强一致性，而最终一致性和它是什么关系？
强一致性其实也是最终一致性的一种。那最终一致性怎么理解？强一致性可以看作不存在延迟的一致性。如果无法容忍延迟就用强一致性，否则就用最终一致性。
3.5 最终一致性和太极拳有什么关系