数据库事务总结
数据库事务总结
数据库事务
Tags: Database Transaction
锁机制
悲观锁
假设更新冲突会发生，所以不管冲突是否真的发生，都使用锁，这样会带来很大的性能损失
悲观锁是很常见的数据库锁方式，尤其是传统数据库，很多带事务的NewSQL数据库也都是使用的悲观锁。
表锁
对数据库整张表进行加锁，在加锁期间，整张表都是不允许使用的。
行锁
针对当前修改的一行数据进行加锁，在加锁期间，还是可以读写其他行数据。
页锁
和数据库内部存储相关，Mysql innodb引擎默认页大小为16KB，数据库在进行数据读取的时候，都是按照页进行读写的，这样可以提升效率，而且可以进行数据缓存，加速数据查询。
页锁就是对整个页进行加锁，同时对范围内数据进行加锁，避免该页数据被其他事务访问。能够显著降低细粒度行锁导致的冲突。
共享锁
允许读取数据，但是不允许修改数据
更新锁
共享锁和排它锁的结合，意味着在做一个更新的时候，一个共享锁在扫描完成符合条件的数据后可能会转化成为排它锁
- 扫描获取更新数据时候，是一个更新锁
- 如果将写入更新，这个时候，事务升级到排它锁，否则转变成共享锁
排它锁
使用锁的时候，任何其他事务都无法修改数据，仅使用NoLock提示或者是未提交读隔离级别时才会进行读取操作
乐观锁
不会锁住任何东西，不依赖数据库事务机制，完全是应用系统层面的东西，比如依靠版本字段来进行对比。
新式的NoSQL数据库以及NewSQL数据库，绝大部分使用的都是乐观锁。
版本号/时间戳
客户端需要进行数据更新，都必须提供版本号或者时间戳，查询的时候，也必须基于版本号或者时间戳进行查询，这样只能查询小于该版本号或者时间戳的数据，以此防止多版本之间的相互影响。
但是该方式受限于全局唯一的版本号生成速度，或者是时间戳精度。
特别是当时间戳发生跳变的时候，很容易出现幻读的情况。
Vector Clock
向量时钟适合于多版本同时提供数据读写操作，同时写入数据导致不一致问题。
向量时钟运行规则如下：
假设有A,B,C三副本都可以写入：
| 时间 | 操作 | 副本A时钟向量 | 副本2时钟向量 | 副本3时钟向量 |
|---|---|---|---|---|
| t0 | 初始状态，一切都很正常 | [A:0, B:0, C:0] | [A:0, B:0, C:0] | [A:0, B:0, C:0] |
| t1 | 副本A写入100，并且同步到B,C | [A:1, B:0, C:0] | [A:1, B:0, C:0] | [A:1, B:0, C:0] |
| t2 | 副本B写入200，并且开始同步到AC | [A:1, B:1, C:0] | [A:1, B:1, C:0] | [A:1, B:1, C:0] |
| t3 | 副本C写入300，但是只同步到A,B有问题 | [A:1, B:1, C:1] | [A:1, B:1, C:0] | [A:1, B:1, C:1] |
| t4 | 副本B写入400 | [A:1, B:1, C:1] | [A:1, B:2, C:0] | [A:1, B:1, C:1] |
| t5 | B的数据开始进行同步，但是这个时候产生了冲突 |
B的数据，比B1新，但是比C1旧，这种情况下就不知道如何选择了。向量时钟并没有给出解决办法，只是提出了冲突检测办法。
向量时钟核心规则：
- 1、 每次修改数据，本节点的版本号 加1，例如上述 step 8中 向B写入，于是从B:1 变成 B:2, 其他节点的版本号不发生变更。
- 2、 每次同步数据(这里需要注意，同步和修改是不一样的写操作哦), 会有三种情况：
a： 本节点的向量版本都要比消息携带过来的向量版本低（小于或等于） 如本节点为 [A:1, B:2,C:3]}， 消息携带过来为 [A:1, B:2,C:4] 或 [A:2, B:3,C:4]等。 这时候合并规则取每个分量的最大值。
b: 本节点的向量版本都要比比消息携带过来的向量版本高，这时候可以认为本地数据比同步过来的数据要新，直接丢弃要同步的版本。
c: 出现冲突，如上述t5，有的分量版本大，有的分量版本小，无法判断出来到底谁是最新版本。就要进行冲突仲裁。
一般的冲突解决办法：
- 向量时钟中再添加一个时间维度，有冲突的时候比较时间，时间新的取胜。
一致性Hash
在Amazon DynamoDB中得到使用。
传统的数据分布是按照Hash取模的方式进行的，在一个节点故障的时候，或者节点数量发生变化的时候，所有的数据都要重分布，这样就会导致数据库长时间不可用。
在一致性Hash中，Hash取模不是按照节点数量的，而是一个比节点数量大很多的值，比如65535等，然后这些值构成一个环形，数据就分布在这65535个虚拟节点中。当有一个节点故障的时候，虚拟节点会按照固定顺时针方向映射到下一个物理节点；当有新节点进入的时候，会在环形中 获取虚拟节点。这样一来，只有部分数据会发生变化，不用重新分布所有数据，大大提升了数据可用性。
一致性哈希算法背后的基本思想是对对象和缓存使用相同的哈希函数。
不仅哈希对象，机器也能利用其优点，即机器得到哈希函数的范围的一个区间，相邻的机器可以接管其邻居的一部分区间如果其邻居离开，也可以抛弃他们自己的一部分区间如果新节点加入且映射到相邻的区间。一致性哈希方法进一步的优点是，客户端应用程序可以计算出联系哪个节点以请求或写一块数据，且不必须有元数据服务器，如谷歌文件系统（GFS）有这样一个中心化的（虽然是集群）元数据服务器，它包含存储服务器和数据分区（在GFS中称为chunk；见[ GL03，页2 ]）之间的映射关系。
一个物理节点能够容纳多少虚拟节点，可以通过CPU，内存，磁盘容量等 方式计算出来。
当数据存在副本的时候，数据必须同时写入多个副本才算成功，比如5副本，则必须至少写入3副本才算成功，写入2副本只能认为写入失败。
R + W > N的关闭表达式必须成立。
一致性Hash策略详细信息可以查看如下链接：
https://blog.csdn.net/mayp1/article/details/51049104?locationNum=9&fps=1
终于可以开始讲事务了，传统数据库事务具有ACID四个特性
原子性 atomicity
操作必须是原子单元，要么都执行，或者都不执行，不存在一部分执行，一部分不执行
一致性 consisitency
事务结束后，所有的数据都必须保持一致，这是数据完整性的要求.
事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性：
- 强一致性：读操作可以立即读到提交的更新操作。
- 弱一致性：提交的更新操作，不一定立即会被读操作读到，此种情况会存在一个不一致窗口，指的是读操作可以读到最新值的一段时间。
- 最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。
其他一致性变体还有：
- 单调一致性：如果一个进程已经读到一个值，那么后续不会读到更早的值。
- 会话一致性：保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。
隔离性 isolation
不同事务操作相同数据时候，每个事务都有各自完整的数据空间，由并发事务所做的修改必须与其他事务所做的修改隔离。事务在查看数据更新时，所有的内部数据结构（比如索引或者是内部数据）都必须是正确的。
隔离问题
脏读
某个事务读到了另一个未提交事务正在处理的数据，而这个事务可能会回滚，造成第一个事务读到的数据是错误的
幻读
事务1对表中数据做了修改，修改了全部数据行，同时，事务2也对这个表数据做了修改，插入了一行新数据。那么以后就会发生事务1用户发现表中还有没有修改的数据行，就好像发生了幻觉一样
一个事务读取两次，得到的记录条数不一致，由于两次读取之间另外一个事务对数据进行了增删。
不可重复读
再一个事务内两次读入数据，但另外一个事务在这期间已经修改了该数据，造成第一个 事务两次读取数据不一致。
一个事务读取同一条记录两次，得到的结果不一致，由于在两次读取之间另外一个事务对此行数据进行了修改。
更新丢失
多个事务同时读取某一数据，一个事务处理好了数据，被另外一个事物写会原值，造成第一个事务更新丢失
隔离级别
未提交读 read uncommitted
最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
实现方式：
事务在读取数据的时候不加锁。
事务在更新该行数据的时候，添加行级共享锁。
这种加锁方式，只能避免同时修改同一行数据导致的冲突，无法避免修改的同时读取该行数据，所以，能读到什么样的数据也就无法保证了。
提交读 read committed
只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。
该隔离级别是很多数据库的默认级别。比如Oracle，SQL Server， DB2， PostgreSQl。
实现方式：
事务在读取该行数据的时候，添加行级共享锁，一旦读完该行数据，立即释放锁。
事务在更新该行数据的时候，必须先对其加行级排它锁，直到事务结束。
读取数据的时候行级共享锁可以避免同时进行修改操作，这样可以避免读取到未提交的数据。
更新的时候添加排它锁，防止其他事务读取该行数据，直到事务结束才可以读取。
可重复读 repeateable reads
在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
Mysql默认使用该隔离级别。
事务在读取该行数据的时候，添加行级共享锁，直到事务结束，才释放锁。
事务在更新该行数据的时候，必须先对其加行级排它锁，直到事务结束。
这种加锁方式，能够保证在读取数据的时候，不会有其它写操作，直到事务结束才允许其它写操作。
这样就可以保证同一事务中多次读取该数据的时候值永远都是一致的，因为事务还没有结束，锁也没有释放，所以肯定不会有修改。
在更新数据的时候，添加了排它锁，避免了其它事务的读取，这样就能防止其他事务的不可重复读。
可串行化 serializable
最高的隔离级别，之前所有的隔离方式都无法解决幻读问题，在可串行化的隔离级别中都可以解决。
实现方式：
事务在读取数据的时候，必须先添加表级共享锁，直到事务结束才释放。
事务在更新数据的时候，必须先添加表级排它锁，直到事务结束才释放。
这种加锁方式，保证了可以并发读取数据，但是不能同时修改表中数据，而且有写操作的时候，读操作只能等待写操作事务结束。以及，有读操作的时候，写操作也只能等待事务结束。也就是说，所有的写操作事务都是线性操作的，相当于单线程操作，同时只会有一个写事务存在，这样就绝对避免了幻读问题，因为事务期间不会有新增操作。
这种隔离级别是锁表的，所以性能相当低下。
快照隔离 snapshot isolation
之前的几种隔离级别都是基于悲观锁的，快照隔离基于乐观锁。能够解决事务读取不一致问题，即可重复读问题。
快照隔离保证，每个事务的操作，都会基于某个特定时刻的数据库状态，所以能够排除其他事务的写入干扰。
这种方式，在某一些情况下，可能无法保证数据一致性，因为无法保证事务是不是会冲突，所以往往需要手工处理冲突。
可串行化快照隔离 serializable snapshot Isolation（SSI）
这种隔离方式是2008年， Michael Cahill在他的博士论文中提出来的。它提供了完整的可串行化，但是性能损失又相对较小。目前之后PostgreSQL 9.1以及FoundationDB有实现该隔离方式，其他数据库库都没有看到。
《Design data-intensive applicaitons》的作者Martin Kleppmann对其非常推崇，认为会是未来数据库的新默认隔离级别。
和快照隔离方式对比，可串行化快照隔离中添加了冲突检测算法，用于检测写入是否可以串行化，以此决定事务是不是要终止。
假设有这么一种场景
| 事务1 | 事务2 |
|---|---|
| 检查医生值班表 | |
| 发现值班人数不足 | |
| 修改值班表，把Alice也添加到值班表中 | |
| 检查医生值班表 | |
| 发现值班人数不足 | |
| 修改值班表，把Bob也添加到值班表中 | |
| 提交事务，事务提交成功 | |
| 提交事务，SSI检测到冲突，事务终止 |
在可串行化快照隔离中，会自动检测到冲突，然后事务2会失败。而快照隔离中，两个事务都会成功，从而导致值班医生数量过多。
持久性 durability
只要事务成功结束，它对数据库所做的更新就必须永久保存下来，即使崩溃之后再恢复，也能够保证存在。
分布式事务/XA事务
XA事务实际上是分布式事务的规范。由X/Open 组织（即现在的 Open Group ）组织定义。
该规范定义了分布式事务处理的模型。
X/Open DTP 模型（ 1994 ）包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。 通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。 所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。
二阶提交协议和三阶提交协议就是根据这一思想衍生出来的。可以说二阶段提交其实就是实现XA分布式事务的关键(确切地说：两阶段提交主要保证了分布式事务的原子性：即所有结点要么全做要么全不做)
二阶段
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作.
所谓的两个阶段是指：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。
- 准备阶段
事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。
准备阶段的详细步骤如下：
- 1）协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
- 2）参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
- 3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
- 提交阶段
如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
提交阶段的详细信息如下：
- 1）协调者节点向所有参与者节点发出”正式提交(commit)”的请求。
- 2）参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
- 3）参与者节点向协调者节点发送”完成”消息。
- 4）协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。
二阶段提交带来的问题：
- 1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
- 2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
- 3、数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
- 4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
由于二阶段提交存在着诸如同步阻塞、单点问题、脑裂等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。
三阶段
与两阶段提交不同的是，三阶段提交有两个改动点。
- 1、引入超时机制。同时在协调者和参与者中都引入超时机制。
- 2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
CanCommit阶段
3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
- 1.事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
- 2.响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
PreCommit阶段
协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
- 1.发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
- 2.事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
- 3.响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
- .发送中断请求 协调者向所有参与者发送abort请求。
- 2.中断事务 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
doCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。
执行提交
- 1.发送提交请求 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送doCommit请求。
- 2.事务提交 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
- 3.响应反馈 事务提交完之后，向协调者发送Ack响应。
- 4.完成事务 协调者接收到所有参与者的ack响应之后，完成事务。
中断事务 协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
- 1.发送中断请求 协调者向所有参与者发送abort请求
- 2.事务回滚 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
- 3.反馈结果 参与者完成事务回滚之后，向协调者发送ACK消息
- 4.中断事务 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）
2PC与3PC的区别
相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
事务补偿机制/TCC(Try/Confirm/Cancel)事务
事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文
CAP
- 一致性（Consistency）
数据操作之后如何保持一致状态。- 可用性（Availability） 高可用性意味着，当集群中的节点崩溃或一些硬件或软件部件由于升级而关闭的时候，系统仍然可以以某种方式继续运行（即允许读写操作），不要求全部可用，允许部分可用。
- 分区容错性（Partition Tolerance） 存在网络分区（网络孤岛，彼此无法连接）的时候，整个系统仍然可以继续运行。也可以理解为节点添加或者删除的时候，系统仍然可用。
CAP理论就是在一个“共享数据系统”中最多只能选择这三个特性中的两个。
如何进行CAP和BASE系统之间的权衡：
- 如果一个系统要求强一致和分区容错的，ACID特性是必需的；
- 如果一个系统可用性和分区容错性比一致性更重要，由此产生的系统可以BASE属性来设计特征。
比如Amazon Dynamo是可用且分区容错，但不严格一致，即一个客户端的写在提交到所有读者后不能被立即看见。也就是说，它是一个CP系统
Google的Bigtable既不选择ACID也不选择BASE，而是第三种CAP选择即一个一致和可用的系统，因此存在网络分区时不能完全操作。它是一个CA系统
| 选择 | 特征 | 举例 |
|---|---|---|
| 一致性+可用性 C + A | 两阶段提交，缓存验证 | 单机数据库 |
| 一致性 + 分区容错性 C + P | 悲观锁，少数分区不可用 | 分布式数据库，分布式锁，HBase |
| 可用性 + 分区容错性 A + P | 乐观锁 | 一些文档数据库，比如SimpleDB |
BASE
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。
BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
接下来看一下BASE中的三要素：
- 1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性-注意，这绝不等价于系统不可用。
比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面- 2、软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时- 3、最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。
柔性事务
阿里云的DRDS的5.3版本宣布实现了柔性事务，见《第三代DRDS分布式SQL引擎全新发布》[引用10]。
柔性事务放弃了隔离性，减小了事务中锁的粒度，使得应用能够更好的利用数据库的并发性能，实现吞吐量的线性扩展。异步执行方式可以更好的适应分布式环境，在网络抖动、节点故障的情况下能够尽量保障服务的可用性（Availability）。
在支付宝的架构设计中，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的。柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。
柔性事务针对分布式事务的解决方法：
- 1、记录日志+补偿
记录事务的开始和结束状态。事务根据日志记录找回事务的当前执行状态，并根据状态决定重试异常步骤，也就是正向补偿，或者回滚上一次执行步骤，也就是反向补偿。- 2、消息
多次重试，也就是发送多次消息，由于要多次重发，所以程序必须是幂等（同一操作反复执行多次结果不变），这是非常具有互联网特征的一种模式。- 3、“无锁”设计
放弃锁是一个解决问题的思路。比如通过乐观锁，大多数是基于版本号来实现
引用
- https://blog.csdn.net/u013007900/article/details/77927723
- http://www.hollischuang.com/archives/943
- 《Design data-intensive applicaitons》
- https://blog.csdn.net/mayp1/article/details/51049104?locationNum=9&fps=1
- http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=23062171&id=5672097
- http://www.gscholar.cn/2014/03/cap.htmls
- https://segmentfault.com/a/1190000005718940
- http://blog.jobbole.com/95632/
- https://blog.csdn.net/u014403546/article/details/54924054
- https://yq.aliyun.com/articles/596656?utm_content=m_50928
- https://www.jianshu.com/p/ab1a1c6b08a1