文档参考：书名：《企业it架构转型之道》-钟华
前文如下：
传统数据库的事务确实非常好地保证了业务的一致性，但在互联网场景下，比如上文提到淘宝订单和互联网金融P2P场景下，就暴露出数据库性能和处理能力上的瓶颈。所以在分布式领域，基于CAP理论和在其基础上延伸出的BASE理论，有人提出了“柔性事务”的概念。
在结合具体实例对柔性事务进行介绍前，有必要对CAP和BASE理论做一个简单的介绍，这样才能让大家更加清晰地理解互联网场景下解决事务问题的思路和理论出发点。
1．CAP理论
2000年7月，加州大学伯克利分校的Eric Brewer教授在分布式计算原则研讨会议上提出CAP猜想。直到2002年，由麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP理论，从而让CAP理论正式成为分布式计算领域的公认定理。
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
“一致性” 指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。一致性指在一个系统中不论数据存放在何处，作为一个整体应是完整和一致的。在分布式系统中，数据通常不会只有一份，用户对数据进行一定的修改操作（增/删/改）之后，为了保证数据的一致性，那么应该对所有数据进行相同的操作并且这些操作应该是同时成功或者同时失败的。
如果一个存储系统可以保证一致性，那么客户读写的数据完全可以保证是最新的。不会发生两个不同的客户端在不同的存储节点中读取到不同副本的情况。
具体来说，系统中对一个数据的读和写虽然包含多个子步骤并且会持续一段时间才能执行完，但是在调用者看来，读操作和写操作都必须是单个即时完成的操作，感知不到其他调用者对这些数据的访问。对一个写操作，如果系统返回了成功，那么之后到达的读请求都必须读到这个新的数据；如果系统返回失败，那么所有的读，无论是之后发起的，还是和写同时发起的，都不能读到这个数据。
“可用性” 指用户在访问数据时可以得到及时的响应。可用性是关于一个系统能够持续不间断使用的问题，严格的定义是高性能可用性。这意味着一个系统从设计到实施都应该能够提供可持续的操作（如读写操作），无论是操作冲突，还是软硬件部分因为升级而导致失效。但是可用性并不意味着数据的一致性，比如读取到的数据是过期数据或脏数据，但对于用户仍有返回数据的情况下，仍然可以被认为是可用的。
同时可用性的要求包含时效性，对于大多数应用而言，超过一定响应时间的服务是没有价值的或者价值量低的。例如，阿里巴巴和Google这样的公司很细小的响应延迟都会对公司的盈利造成损失。
“分区容错性” 指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。Gilbert和Lynch是这样定义分区容忍性的：除了整个网络的故障外，其他的故障（集）都不能导致整个系统无法正确响应。
一旦针对同一服务的存储系统分布到了多个节点后，整个存储系统就存在分区的可能性。分区不是简单的理解为物理存储节点的分布，而且是节点间网络通信中断或报文丢失等。比如，两个存储节点之间联通的网络断开（无论长时间或者短暂的），就形成了分区，一旦开始将数据和逻辑分布在不同的节点上，就有形成分区的风险。假定网线被切断，分区就形成了，节点A无法和节点B通信。正如数据库的数据在进行了分库分表后，就是典型的分区状态。
举例说明
为了能更直观地了解CAP定理，我们举一个简单的例子。某用户在电商平台上搜索到一件喜欢的衣服，但是用户并没有立即购买，她选择先浏览其他类似商品。与此同时，另一用户也看上了这件衣服并直接下单创建了订单，而恰巧这件衣服的库存仅剩下最后一件，那么当第一个用户在返回页面决定购买该衣服时，由于这件衣服的库存已经为零，理论上她是不能再购买该衣服的。假设网站的数据是以分布式系统的方式存储在多个机房或多个数据库中，那么，一个商品的库存信息就被存储在不同地方，那必然存在数据的同步和一致性问题。如果第一个用户在进行衣服订单的创建时，该请求所访问的数据库没有得到及时更新（在该数据库中，该商品的库存本应该是零），那么第一用户可能也为该衣服进行了成功的订单创建，就出现了商品超卖的情况。这里所讲的就是分布式系统中的数据一致性问题。
在这个例子中，如何解决数据一致性的问题？一个简易的方案就是建立类似操作系统中锁的机制，要求确保所有数据节点的数据均同步之后，才能进行数据的访问操作，也就是在第二个客户对该衣服创建订单时，商品的库存修改为零，接着等到该库存信息在所有数据库上都同步后，再返回给客户告知订单成功创建。在此过程中，系统不接受对该衣服库存数据的修改操作，所以等到第一个客户希望创建订单时，因为所有数据库中该商品的库存信息都已经被同步为零，所以系统会给第一个客户做出库存不足的提示，而无法进行订单的创建。但这引入了一个新问题，就是可用性问题。由于不同数据节点间的数据同步是需要时间的，而且大量采用锁机制会给数据层带来严重的性能瓶颈，从而可能导致平台在业务繁忙时的服务瘫痪或糟糕的用户体验（点击平台上一个业务请求所需要等待的时间过长）。一个客户无法访问的服务对任何人都没有价值，这就是分布式系统中的可用性问题。
另一个做法就是商品的库存数据只保存一份，不做复制，这样就不会存在数据一致性的问题。而因为网站的数据量太大，一个数据节点无法容纳如此大容量的数据，所以把整体数据分割成若干部分，每一部分存储在不同节点上，这也就是典型的数据进行分库分表的操作，这样就能解决可用性的问题。但这样也会有个很明显的问题，假如某一时刻数据节点间的网络阻塞或者切断了，那么会导致网站可能获取不到完整的数据。这就是分区容忍性的问题。所以，三个核心需求之间无法同时得到完全的保证。
CAP之间的取舍
根据前面的介绍，CAP理论的核心是：一个分布式系统不可能同时很好地满足一致性、可用性和分区容错性这三个需求，最多只能同时较好地满足两个。
CAP定理并不意味着所有系统的设计都必须抛弃三个要素之中的一个。CAP三者可以在一定程度上衡量，并不是非黑即白的，例如可用性从0%到100%有不同等级。显然我们有几种组合选择问题。
1）放弃分区容忍性。为了避免分区问题发生，一种做法是将所有与事务相关的东西都放到一台机器上，但这并不能100%地保证，因为在一台机器上还是有可能部分失败的情况发生，虽然这种情况下由分区问题带来的负面效果不易被察觉到。但是，系统从分布式系统退化为单机系统，从根本上失去了可扩展性，这个选择会严重影响系统规模。实践中，大部分人认为位于单一地点的数据中心内部是没有分区的，因此在单一数据中心之内可以选择CA（一致性，可用性）; CAP理论出现之前，系统都默认这样的设计思路，包括传统数据库在内。 然而在今天互联网时代，各种业务的数据量都出现了爆发式增长的态势，单一数据中心越来越多的出现分区的情况，这就动摇了以CA为取向的设计基础。
2）放弃可用性。相对于放弃分区容忍性来说，其反面就是放弃可用性。一旦遇到分区事件，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务。 在多个节点上控制这一点会相当复杂，而且恢复的节点需要处理逻辑，以便平滑地返回服务状态。
3）放弃一致性。其实，在互联网应用没有盛行之前，传统应用中出现分区的情况并不多见，系统在大多数情况下是允许完美的C（一致性）和A（可用性）。但当分区存在或者可感知其影响的情况下，就要预备一种策略去探知分区并显式处理其影响。这样的策略一般分为三个步骤：探知分区发生，进入显式的分区模式以限制某些操作，启动恢复过程以恢复数据一致性并补偿分区期间发生的错误。分区期间，独立且能自我保证一致性的节点子集合可以继续执行操作，只是无法保证全局范围的不变性约束不受破坏。 数据分片就是这样的例子，架构师预先将数据划分到不同的分区节点，分区期间单个数据分片多半可以继续操作。相反，如果被分区的是内在关系密切的状态，或者有某些全局性的不变性约束非保持不可，那么最好的情况是只有分区一侧可以进行操作，最坏情况是操作完全不能进行。
2．BASE理论
eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出了BASE理论。BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency, CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。
❑“基本可用”是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
❑“柔性状态”是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是柔性状态的体现。MySQL Replication的异步复制也是一种柔性状态体现。
❑“最终一致性”是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
ACID和BASE的区别与联系
ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常用的设计理念，追求强一致性模型；BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
ACID（英文中是酸）和BASE（英文中有碱性的意思）在化学的世界中两者（酸和碱）是完全对立的，具有独特而相反的性质。在实际的系统设计中，不同业务场景对一致性要求是不同的，因此ACID和BASE一般在系统中又会结合使用。那为什么在今天互联网应用中会更广泛采用柔性事务而放弃传统数据库事务来解决业务事务性问题？
刚刚提到，柔性事务是由于互联网应用的需求产生的，那么需要看互联网应用的核心诉求是什么。互联网应用的最核心需求是高可用（也就是BASE的BA）。 对于这一点可能很多非互联网企业的读者会产生怀疑，或许是遇到过或看到过很多的互联网平台出现系统崩塌和不可访问的情况，就让人感觉互联网应用出现不可用是一件经常发生的事情，而且看起来对业务的影响并没有多大。而作者所面对的金融、政府职能单位的技术同仁，都会强调自身业务对高可用性的要求要远超互联网企业，我想说这是一个不小的误解。
在今天互联网时代有着上百万的互联网的应用和平台，我认为其中很大一部分的平台所依靠的技术能力和架构都是有明显缺陷和隐患的，这也直接导致有些平台所提供的服务并不是稳定可靠的，所以才给人有了这样的印象：互联网平台出现问题很正常，对业务不会有太大影响。但从专业的角度来说，一个专业的互联网平台一定首先考虑的是系统服务能力的高可用，因为服务不可用意味着就是商业损失。淘宝交易高峰10秒钟不可用，可能损失价值千万的交易订单，如果在双11这一天，10秒钟可能影响的是上亿的订单交易。
服务的不可用除了造成金钱上的损失外，更为严重的是造成对平台的伤害。平台的服务不可用一定会给客户带来商业损失或者糟糕的用户体验，同时也会让这些客户失去对平台的信心，如果造成平台客户流失将会给这个互联网平台带来更为可怕的后果。
对于如何实现高可用，我们认为：
高可用=系统构建在多机=分布式系统
高性能=分布式系统的副产品
今天大家都知道淘宝去IOE的故事，但当年去Oracle排名第一位的需求不是性能，而是因为Oracle是系统单点。一旦Oracle不可用，整个系统100%不可用，而Oracle每年总是会出1次故障。既然为了高可用采用了分布式系统，那么分布式系统特性决定了柔性事务的第二个特性：最终一致。
分布式系统内通信和单机内通信最大的区别是：单机系统总线不会丢消息，而网络会。
一台向另一台机器通信的结果可能是收到、未收到、不知道收到没收到。消息不可靠带来的副作用是：数据或者状态在多机之间同步的成本很高。
大家都知道Paxos协议。在多机间通信不存在伪造或篡改的前提下，可以经由Paxos协议达成一致性。成本是发给Paxos系统的信息（数据）需要至少同步发送到一半以上多数（Quorum）的机器确认后，才能认为是成功。这样大幅增加了信息更新的延迟，因此分布式系统的首选不是这种强同步而是最终一致。而采用最终一致，一定会产生柔性状态。
