理解分布式之前，需要理解一个问题就是”事务”。
1. 本地事务
事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。
1.1 ACID理论
事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的ACID特性，指数据库事务正确执行的四个基本特性的缩写。
- 原子性（Atomicity）
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。
- 一致性（Consistency）
在事务开始之前和事务结束以后，数据库数据的一致性约束没有被破坏。
- 隔离性（Isolation）
数据库允许多个并发事务同时对数据进行读写和修改的能力，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
- 持久性（Durability)
事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
本地事务ACID实际上可用”统一提交，失败回滚“几个字总结，严格保证了同一事务内数据的一致性！
而分布式事务不能实现这种ACID。因为有CAP理论约束。接下来我们来了解一下，分布式中是如何保证以上特性的，那么就有了一个著名的CAP理论。
2. 分布式事务
2.1 CAP 理论
在设计一个大规模可扩放的网络服务时候会遇到三个特性：一致性（consistency）、可用性（Availability）、分区容错（partition-tolerance）都需要的情景.
CAP定律说的是在一个分布式计算机系统中，一致性，可用性和分区容错性这三种保证无法同时得到满足，最多满足两个。
2.2 流程演示
该场景整体分为5个流程：
流程一、客户端发送请求(如:添加订单、修改订单、删除订单)
流程二、Web业务层处理业务，并修改存储成数据信息
流程三、存储层内部Master与Backup的数据同步
流程四、Web业务层从存储层取出数据
流程五、Web业务层返回数据给客户端
1. 一致性(Consistency)
一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。
一致性实现目标：
Web业务层向主Master写数据库成功，从Backup读数据也成功。
2. 可用性(Availability)
所有请求都有响应，且不会出现响应超时或响应错误。对于可用性的衡量标准如下：
| 可用性分类 | 可用水平（%） | 一年中可容忍停机时间 |
|---|---|---|
| 容错可用性 | 99.9999 | <1 min |
| 极高可用性 | 99.999 | <5 min |
| 具有故障自动恢复能力的可用性 | 99.99 | <53 min |
| 高可用性 | 99.9 | <8.8h |
| 商品可用性 | 99 | <43.8 min |
可用性实现目标：
- 当Master正在被更新，Backup数据库接收到数据查询的请求则立即能够响应数据查询结果。
- backup数据库不允许出现响应超时或响应错误。
- 写入Master主数据库后要将数据同步到从数据库。
- 由于要保证Backup从数据库的可用性，不可将Backup从数据库中的资源进行锁定。
- 即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据/或者默认数据，但不能返回错误或响应超时。
3. 分区容错性(Partition tolerance)
分布式系统中，尽管部分节点出现任何消息丢失或者故障，系统应继续运行。
通常分布式系统的各各结点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可对外提供服务。
分区容错性实现目标：
主数据库向从数据库同步数据失败不影响读写操作。
其一个结点挂掉不影响另一个结点对外提供服务。
必要实现流程：
- 尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现松耦合。
- 添加Backup从数据库结点，其中一个Backup从结点挂掉其它Backup从结点提供服务。
分区容错性特点：
分区容忍性分是布式系统具备的基本能力。
2.3 CAP牺牲谁
假设在N1和N2之间网络断开的时候，
A、用户向Host1发送数据更新请求，那Host1中的数据Data(0)将被更新为Data(1)
B、若此时Host1和Host2网络是断开的，所以分布式系统同步操作将失败，Host2中的数据依旧是Data(0)
C、有用户向Host2发送数据读取请求，由于数据还没有进行同步，Process2没办法立即给用户返回最新的数据V1，那么将面临两个选择。
第一，牺牲数据一致性(c)，响应旧的数据Data(0)给用户；
第二，牺牲可用性(A)，阻塞等待，直到网络连接恢复，数据同步完成之后，再给用户响应最新的数据Data(1)。
这个过程，证明了要满足分区容错性(p)的分布式系统，只能在一致性(C)和可用性(A)两者中，选择其中一个。
1. CA 放弃 P （别你别叫分布式了）
一个分布式系统中，不可能存在不满足P，放弃分区容错性(p)，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统。
对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P。
2. CP 放弃 A （银行转账保证一致性）
如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。
放弃可用性，追求一致性和分区容错性，如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。
场景：
跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。
3. AP 放弃 C （常用，例如社交系统）
放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。实现AP，前提是只要用户可以接受所查询的到数据在一定时间内不是最新的即可。
通常实现AP都会保证最终一致性，后面讲的BASE理论就是根据AP来扩展的。
2.4 CAP理论如何设计一个电商系统？
对于用户模块，包括登录，个人设置，个人订单，购物车，收藏夹等，这些模块保证AP，数据短时间不一致不影响使用。
订单模块的下单付款扣减库存操作是整个系统的核心，CA都需要保证，极端情况下面牺牲A保证C 。
商品模块的商品上下架和库存管理保证CP。
搜索功能因为本身就不是实时性非常高的模块，所以保证AP就可以了。
促销是短时间的数据不一致，结果就是优惠信息看不到，但是已有的优惠要保证可用，而且优惠可以提前预计算，所以可以保证AP。
支付这一块是独立的系统，或者使用第三方的支付宝，微信。其实CAP是由第三方来保证的，支付系统是一个对CAP要求极高的系统，C是必须要保证的，AP中A相对更重要，不能因为分区，导致所有人都不能支付。
3. BASE 理论（基本可用+软状态+最终一致）
BASE 是 CAP 理论中 AP 方案的延伸。要求服务基本可用，不同节点数据可以暂时不一样，保证最终一致性。
3.1 BASE 理论
BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。
核心思想:
即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
3.2 ACID和BASE
两个对冲理念：ACID和BASE。
ACID是传统数据库常用的设计理念，追求强一致性模型。
BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
3.3 Basically Available(基本可用)
实际上就是两个妥协。
对响应上时间的妥协：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
对功能损失的妥协：正常情况下，在一个电子商务网站（比如淘宝）上购物，消费者几乎能够顺利地完成每一笔订单。但在一些节日大促购物高峰的时候（比如双十一、双十二），由于消费者的购物行为激增，为了保护系统的稳定性（或者保证一致性），部分消费者可能会被引导到一个降级页面。
3.4 Soft state（软状态）
原子性（硬状态） -> 要求多个节点的数据副本都是一致的,这是一种”硬状态”
软状态（弱状态） -> 允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟。
3.5 Eventually consistent（最终一致性）
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。
稍微官方一点的说法就是：
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。
