以下为 mindmanager 的预览

CAP

历史

「CAP」理论由Eric Brewer在2000年PODC会议上提出

是Eric Brewer在Inktomi期间研发搜索引擎、分布式web缓存时得出的一个猜想

后来Seth Gilbert和Nancy Lynch对其进行了证明

概述

版本

第一版解释

• 对于一个分布式计算系统，不可能同时满足一致性、可用性、分区容错性三个设计约束

第二版解释

• 在一个分布式系统中，当涉及读写操作时，只能保证一致性、可用性、分区容错性三者中的二个，另一个必须被牺牲

二个版本差异点

• 分布式：连接并共享数据。分布式系统并不一定会互联和共享数据，比如：Memcache 不符合 CAP 理论，Mysql 符合

• CAP 关注的是对数据的读写操作，而不是分布式系统的所有功能。
  比如 ZK 的选举机制就不是 CAP 探讨的对象

三个要素只能实现两点，不能兼顾

一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

CAP理论断言任何基于网络的数据共享系统，
最多只能满足数据一致性、可用性、分区容忍性三要素中的两个要素。
但是通过显式处理分区情形，系统设计师可以做到优化数据一致性和可用性，进而取得三者之间的平衡。

分布式系统在设计时只能满足两种，无法兼顾三种。

一个分布式系统里面，节点组成的网络本来应该是连通的。
然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。
然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。
要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。
总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。
为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

对大型网站，可用性与分区容忍性优先级要高于数据一致性，
一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。

CAP定理（布鲁尔定理）

又被称作布鲁尔定理（Brewer’s theorem）

C、A、P三者最多只能满足其中两个，和FLP定理一样，CAP定理也指示了一个不可达的结果（impossibility result）

对于分布式系统工程实践，CAP理论更适合描述：在满足分区容错的前提下，没有算法能同时满足数据一致性和服务可用性。

In a network subject to communication failures,
it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.

分布式系统无法同时确保一致性、可用性和分区容忍性，设计中往往需要弱化对某个特性的需求。分布式系统最多只能保证其中的两项特性。

例如

• 网络出现分区时，系统无法同时保证一致性和可用性。

• 要么，节点因没有得到其他节点的确认而不应答（牺牲可用性）；

• 要么，节点只能应答非一致的结果（牺牲一致性）

一个分布式系统只能满足 一致性 可用性 分区容错性中的两项

分区容错性是分布式系统的基本要求，所有一般在C和A做权衡。

因为如果放弃P只能采用单点部署的方式，这样就放弃了可扩展性，也就无所谓的分布式系统了。

一个分布式系统只能满足 一致性 可用性 分区容错性中的两项
分区容错性是分布式系统的基本要求，所有一般在C和A做权衡。
因为如果放弃P只能采用单点部署的方式，这样就放弃了可扩展性，也就无所谓的分布式系统了。
放弃A，如果发生网络故障或为了保证一致性，那么受到影响的服务需要等待一定时间，这段时间内系统无法对外提供正常的服务。
放弃C，实际上是放弃数据的强一致性，而保留数据的最终一致性。（强一致性，是指针对一个数据的更新操作成功后，所有用户都能读取到最新的数据）

关注点

互相连接

数据而非系统

涉及读写操作

CAP 是忽略网络延迟的

正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足CA

设计约束

一致性Consistency

版本

• 版本一：所有节点同一时刻能看到相同数据

• 版本二：对某个制定的客户端，保证读操作能够返回最新的写操作结果

这里的一致性指是「 线性一致性 」

C: Consistency 一致性

• Consistency（一致性）

数据是否在多个副本之间能否保持一致

任何事物应该都是原子的，所有副本上的状态都是事物成功提交后的结果，并保持强一致

一致性(Consistency) 客户端知道一系列的操作都会同时发生(生效)

所有节点访问同一份最新的数据副本

• 设置定时器，放弃强一致性，达到最终一致性

任何时候所有的应用程序都能访问得到相同的数据

• 即所有的节点都能访问同一份最新的数据副本

Consistency 一致性

• ACID理论

Consistency

• 因为在分布式的系统中P一定是要被考虑到的，所以就只剩下 AP和CP两个选项

  • 可用性

Consistency(一致性)

• 如果系统一个操作返回成功，那么之后的读请求都必须读取到这个数据

• 如果系统一个操作返回失败，那么之后所有的读操作都不能读取这个数据

• 对调用者而言数据具有强一致性(strong consistency)。即原子性 atomic、线性一致性 linearizable consistency

可用性Availability

要素

• （1）有限时间内

• （2）返回正常结果

版本

• 版本一：每个请求都能得到成功或失败的响应

• 版本二：非故障的节点在合理时间内返回合理的响应（不是错误或尝试的响应）

A: Availability 可用性(指的是快速获取数据)

可用性

• 系统服务一直处于可用状态.(总能在有限时间内返回结果)

保证每个请求不管成功或失败都有响应

可用性(Availability)

• 每个操作都必须以可预期的响应结束

• 每次请求都能获取到非错的响应，所有的读和写都必须要能终止

任何时候任何程序都可以读写数据

• 在集群中一部分节点故障后，集群整体是否还能响应客户的读写请求

• 即对数据更新具备高可用性

Availability

• 因为在分布式的系统中P一定是要被考虑到的，所以就只剩下 AP和CP两个选项

可用性（Availability）

• 系统提供的服务必须一直处于可用状态，对于每一个操作请求总是能够在有限时间（区分场景）内返回结果

• 所有读写请求在一定时间内响应，可终止、不会一直等待

• 非故障的节点再合理的时间内返回合理的响应

• 系统能在有限时间内完成对操作请求的应答

分区容错性Partition tolerance

概述

• 分区容错性(Partition tolerance)

  • P: Tolerance of network Partition 分区容忍性(分布式)

• 即使出现单个组件无法可用,操作依然可以完成

• 必须需要实现

  • 遇到某节点或网络分区故障的时候仍然可以提供一致性和可用性的服务

  • 对于分布式系统来说，P是不能放弃的

• 分布式系统在遇到任何网络分区故障的时候，
  仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

• 要保证分区容错, 就只能在一致性和可用性之间 选择一个,如果选择可用性,则数据会不一致,如果保证数据一致,则不可用.

• 当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。
  这时分区就是无法容忍的。

• 提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。
  容忍性就提高了。

版本

• 版本一：出现消息丢失或分区错误时系统能够继续运行

• 版本二：当出现网络分区后，系统能后继续履行职责

网络分区容错性

• 当系统出现分区,出现多个网络分区,分区间网络不可达, 要保证能访问数据,就一定需要保证数据冗余多副本保存.所以网络分区容错可以理解为数据副本冗余.
  即使因为网络或者其他原因,某些节点退出,分布式系统也能恢复(要求数据冗余). 即使分布式系统内部不需要互相访问,也要考虑节点挂掉的影响.

• 分区容错性是一个最基本的要求。因为既然是一个分布式系统，
  那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。
  而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。
  因此系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡

系统可以跨网络分区线性的伸缩和扩展

• 分区相当于对通信的实现要求，系统如果不能在时限内达成数据的一致性，就意味着发生了分区的情况

Partition Tolerance 分隔容忍

Partition-tolerance

• 大部分的分布式系统都分布在不同子网络之间，每个子网络就属于一个分区，分区容错指的就是区间的通信有可能失败，那么如果通信失败则就会出现多个分区，所以在分布式的系统中P一定是满足的，除非你的服务只部署在一台机器上面

系统在遇到任何网络分区故障时，仍然能够保证对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

在网络分区的情况下，被分隔的节点仍能正常对外服务

• 当出现网络分区后，系统能够继续”履行职责”

系统中的网络可能发生分区故障，即节点之间的通信无法保障。
而网络故障不应该影响到系统正常服务

限制条件

• 网络本身无法做到100%可靠，所以必须保证分区容忍性

组合(应用)

CA

放弃分区容错性，加强一致性和可用性，
其实就是传统的单机数据库的选择

弱化分区容忍性

• 现实中，网络分区出现概率较小，但很难完全避免。
  两阶段的提交算法，某些关系型数据库以及 ZooKeeper 主要考虑了这种设计。
  实践中，网络可以通过双通道等机制增强可靠性，实现高稳定的网络通信。

不能容忍网络错误或节点错误，一旦出现，整个系统拒绝写请求

• 网络本身无法做到100%可靠，有可能出故障，所以分区时一个必然的现象。

• 因为系统不知道对面节点是否挂掉还是只是网络问题，唯一安全做法是把自己变成只读

• 单节点挂了 ,就完蛋了

关注一致性和可用性

• 需要非常严格的全体一致性协议

  • 2PC(两阶段提交)

  • 3PC(三阶段提交)

• 此时的可用性的不是指多节点高可用的可用性

CP

关注一致性和分区容忍性

• 大多数一致性协议

  • Paxos算法

  • Quorum类的算法

保证大多数节点数据一致，
少数节点会在数据未同步到最新版本之前处于不可用状态

放弃可用性，追求一致性和分区容错性，
基本不会选择，网络问题会直接让整个系统不可用

zk是放弃可用性

放弃A，如果发生网络故障或为了保证一致性

• 那么受到影响的服务需要等待一定时间，
  这段时间内系统无法对外提供正常的服务。

既保证最新数据返回

取到非最新数据时返回错误

CP 架构

• 二个节点N1、N2，复制通道中断，数据无法同步到 N2，
  客户端访问 N2，返回 error，违背了可用性，因此只能选择 CP

弱化可用性

• 对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。

• Paxos、Raft 等共识算法，主要处理这种情况。
  在 Paxos 类算法中，可能存在着无法提供可用结果的情形，同时允许少数节点离线。

AP

关注可用性和分区容忍性

• 不能达成一致性要求，需要给出数据冲突，给出数据冲突就需要维护数据版本

• 保证都能返回数据，可以多版本

  • 二个节点N1、N2，复制通道中断，数据无法同步到 N2，
    客户端访问 N2，返回 旧的值，不能满足一致性，因此只能选择AP

Dynamo

AP

• 例如很多NoSQL系统就是如此，异步复制，一致性很弱

• 放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，
  这是很多分布式系统设计时的选择，

放弃C，实际上是放弃数据的强一致性，而保留数据的最终一致性。

• 强一致性，是指针对一个数据的更新操作成功后，所有用户都能读取到最新的数据

总结：基于 Paxos 算法构建的分布式系统，属于 CAP 架构哪一种？

• Paxos 算法提供最终一致性保证

  • 符合 CP 方案

• 大部分集群方案都是 AP 方案

弱化一致性。

• 对结果一致性不敏感的应用，
  如：静态页面内容、实时性较弱的查询类数据库等。允许一段时间才最终更新成功，期间不保证一致性

实例

1.关系型数据库一般选择C（一致性）与A（可用性）。

2.HBase选择了C（一致性）与P（分区可容忍性）

3.Cassandra选择了A（可用性）与P（分区可容忍性）

CAP关键细节点

关注粒度是数据，而不是整个系统

忽略网络延迟的

正常运行情况下，不存在 CP、AP 的选择，可以同时满足 CA

分区发生时选择 CP 或 AP

没有分区时，也要考虑如何保证 CA

放弃并不等于什么都不做，需要为分区恢复后做准备

误区

关于P的理解

Partition：网络分区，即因网络因素将系统分隔为多个单独的部分

有人说，网络分区的情况发生的概率非常小，是不是不用考虑P，保证CA就好

• 现实情况是我们面对的是一个不可靠的网络、有一定的概率宕机的设备，
  这两个因素都会导致Partition，因此分布式系统实现中P是一个必须项，而不是一个可选项。

CAP中P的定义

• In order to model partition tolerance, the network will be allowed lose arbitrarily many messages sent from one node to another.

• 网络允许从一个节点到另一个的任意的多个消息的丢失

• 分区容忍性意味着通过降低系统的其他属性来开发一个复制策略。

网络分区、网络丢包、节点宕机都符合CAP中P的定义

CA非0/1的选择

工程实践中一致性有不同程度，可用性也有不同等级，
在保证分区容错性的前提下，放宽约束后可以兼容一致性和可用性，两者不是非此即彼

CAP定理中的一致性指强一致性

• 强一致性要求多个节点组成的被调用能像单个节点一样允许、操作具备原子性，在数据和时序上都有要求

• 放宽时间、时序要求

  • sequential consistency（序列一致性）

    • 不要去时序一致

  • enventual consistency（最终一致性）

    • 放宽对时间的要求

可用性在CAP定理中指所有读写操作必须要能终止

• 实际应用中从主调、被调视觉来看，可用性具有不同的含义

  • 当P(网络分区)出现时，主调可以只支持读操作，通过牺牲部分可用性达成数据一致

• 工程实践中，较常见的做法是通过异步拷贝副本(asynchronous replication)、quorum/NRW，
  实现在调用端看来数据强一致、被调端最终一致，在调用端看来服务可用、被调端允许部分节点不可用(或被网络分隔)的效果

跳出CAP

CAP理论对实现分布式系统具有指导意义，
但CAP理论并没有涵盖分布式工程实践中的所有重要因素

延时（latency）

• 衡量系统可用性、与用户体验直接相关的一项重要指标

• 加上延时考虑

  • CAP理论修改版：PACELC

    • 如果出现P(网络分区)，如何在A(服务可用性)、C(数据一致性)之间选择；
      否则，如何在L(延时)、C(数据一致性)之间选择。

• 如果要达到强一致性、多个副本数据一致，必然增加延时

CAP理论中的可用性要求操作能终止、不无休止地进行

其他

为什么不能都保证

分布式领域CAP理论，

Consistency(一致性), 数据一致更新，所有数据变动都是同步的

Availability(可用性), 好的响应性能

Partition tolerance(分区容忍性) 可靠性

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

BASE

概述

BASE 理论是 Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。

完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，
并允许数据在一段时间内是不一致的，但最终达到一致状态

指基本可以、软状态、最终一致性，核心思想是即使无法做到强一致性，但可以采用适合的方式达到最终一致性

BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的

BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：

约束

基本可用（Basically Available）

概述

• 指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

• 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，
  这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子。

• 支持分区失败(e.g. sharding碎片划分数据库)

• 分布式系统再出现故障时，允许损失部分可用性，即保证核心可用

• 关键字：部分、核心，根据业务选择

• 在分布式系统出现不可预知的故障时, 允许损失部分可用性

损失

• 响应时间上的损失

  • 响应时间增长.但不会失败

  • 响应时间上的损失

    • 正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，
      但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。

• 功能上的损失

  • 部分功能不可用

  • 系统功能上的损失，网页降级

  • 当流量高峰期时，
    屏蔽一些功能的使用以保证系统稳定性（服务降级）

    • 正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，
      但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态（ Soft State）

指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，
即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

允许系统存在中间状态，而该中间状态不会影响系统整体可用性

• 不同节点的数据副本之间进行数据同步的过程存在延时

• 状态可以有一段时间不同步，异步。

Soft-state –软状态/柔性事务

• “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的

• 和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，
  即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。比如支付过程

最终一致性（ Eventual Consistency）

概述

• 强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。
  因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

• 所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态

• 允许数据在一段时间内是不一致的，但系统中的所有数据副本在经过一段时间的同步之后，最终能够达到一致的状态

  • 需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

• 关键字

  • 一定时间、最终。不同的数据能够容忍的不一致时间是不同的

分类

• （1）因果一致性（Causal consistency）

  • 即进程A在更新完数据后通知进程B，那么之后进程B对该项数据的范围都是进程A更新后的最新值。

• （2）读己之所写（Read your writes）

  • 进程A更新一项数据后，它自己总是能访问到自己更新过的最新值。

• （3）会话一致性（Session consistency）

  • 将数据一致性框定在会话当中，在一个会话当中实现读己之所写的一致性。
    即执行更新后，客户端在同一个会话中始终能读到该项数据的最新值

• （4）单调读一致性（Monotonic read consistency）

  • 如果一个进程从系统中读取出一个数据项的某个值后，
    那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

• （5）单调写一致性（Monotoic write consistency）

  • 一个系统需要保证来自同一个进程的写操作被顺序执行。

核心思想

即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，
采用适当的方式来使系统达到最终一致性（Eventual consistency）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是

无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，
采用适当的方式来使系统达到最终一致性（Eventual consistency）。

其他

BASE（FROM EBay）

过程

• 分布式事务转化成多个本地事务

• 在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。

• 在第二阶段，分别读出消息队列（但不删除），
  通过判断更新记录表 updates_applied 来检测相关记录是否被执行，
  未被执行的记录会修改 user 表，
  然后增加一条操作记录到 updates_applied，
  事务执行成功之后再删除队列。

跨数据库两段提交事务

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，
JavaEE中的JTA事务可以支持2PC。
因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。

BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：

Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)

Soft state软状态 状态可以有一段时间不同步，异步。

Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

实现

BASE思想的主要实现有

1.按功能划分数据库

2.sharding碎片

BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，
那么就要以一致性或容忍性为牺牲，BASE思想的方案在性能上还是有潜力可挖的。

现在NOSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等，NOSQL应该有下面两个流派：

流派

• 1. Key-Value存储，如Amaze Dynamo等，可根据CAP三原则灵活选择不同倾向的数据库产品。
• 2. 领域模型 + 分布式缓存 + 存储 （Qi4j和NoSql运动），
     可根据CAP三原则结合自己项目定制灵活的分布式方案，难度高。

共同点

• 都是关系数据库SQL以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，
  将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。

不同点

• NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX，可以适合非Java如PHP RUBY等领域，是一种可以拿来就用的产品，
  而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。

色彩

红色

蓝色

绿色

CAP和BASE相关点

CAP 理论时忽略延时的，而实际应用中延时是无法避免的

CP 实际上也是最终一致性，一定时间是几毫米而已

AP 方案中牺牲一致性只是指分区期间，而不是永远放弃一致性

分区故障恢复后，系统应达到最终一致性

CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸

ACID

事务

程序执行单元，里面的操作要么全部执行成功，要么全部执行失败

定义

事务的ACID特性

ACID 也是一种比较出名的描述一致性的原则， 通常出现在分布式数据库等基于事务过程的系统中。 以牺牲可用性为代价

A即 Atomicity（原子性）。每次事务是原子的，事务包含的所有操作要么全部成功，要么全部不执行。 一旦有操作失败，则需要回退状态到执行事务之前

C即 Consistency（一致性）。
数据库的状态在事务执行前后的状态是一致的和完整的，无中间状态。
即只能处于成功事务提交后的状态

I 即 Isolation（隔离性）。各种事务可以并发执行，但彼此之间互相不影响。
按照标准 SQL 规范，从弱到强可以分为未授权读取、授权读取、可重复读取和串行化四种隔离等级

D即 Durability（持久性）。 状态的改变是持久的，不会失效。
一旦某个事务提交，则它造成的状态变更就是永久性的

关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区

与之相对应的是BASE（Basic Availability，Soft-state，Eventual Consistency）原则。
BASE 原则面向大型高可用分布式系统，主张牺牲掉对强一致性的追求，而实现最终一致性，来换取一定的可用性。

数据库管理系统为了保证事务的正确性而提出来的一个理论

ACID 是数据库事务完整性理论

约束

原子性（Atomicity）

Atomicity(目标)

事务是最小的执行单位

一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

即不可分割，事务要么全部被执行，要么全部不执行。
如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生变化；
如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换。

对一个事务内的操作来说，整个事务是原子的，要么内部的执行（插入或更新）全部成功，
要么事务失败，所有操作回滚

事务是一个不可分割的整体，所有操作要么全做，要么全不做；只要事务中有一个操作出错，
回滚到事务开始前的状态的话，那么之前已经执行的所有操作都是无效的，都应该回滚到开始前的状态

事务中的操作是原子的，一个事务中的所有操作，要么全部完成，要么全部不完成，不会再中间某个环节结束

事务中各项操作，要么全做要么不做，任何一项操作的失败都会导致整个事务的失败

一个事务必须是一个不可分割的最小工作单元，整个事务的全部操作，要么全部提交成功，要么全部失败回滚，不可能执行其中一部分。

一致性（Consistency）

Consistency(约束)

在事务开始之前和事务结束以后，数据库的完整性没有被破坏。
这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

事务的执行使得数据库从一种正确状态转换成另外一种正确状态。

不受并发等影响，事务执行成功，则数据是确定的

事务执行前后，数据从一个状态到另一个状态必须是一致的，
比如A向B转账（A、B的总金额就是一个一致性状态），不可能出现A扣了钱，B却没收到的情况发生。

再事务开始之前和事务结束以后，数据库的完整性没有被破坏

在事务开始或结束时，数据库应该在一致状态。

• 数据库事务执行的结果总是从一个一致性的状态转换到另外一个一致性状态。没有中间状态

执行完后，数据保证一致

• 事务结束后系统状态是一样的

• 一旦事务完成,系统必须确保所建模业务一致状态

规则一致性

• 主键约束

• 唯一键约束

• 外键约束

逻辑一致性

• 悲观锁

• 乐观锁

• 双重锁检查

• balking模式

隔离性（Isolation）

概述

• 数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
  事务隔离分为不同级别

• 事务与事务之间不受影响，中间状态不可见

  • 并发执行的事务彼此无法看到对方的中间状态

  • 防止多个事务并发执行时由于交叉执行而导致数据的不一致

  • 一个事务的执行不能被其它事务干扰

    • 并发执行时，事务不被其他事务所干扰

  • 事务将假定只有它自己在操作数据库，彼此不知晓。

  • 事务之间的隔离级别，对其他事务的可见性。
    通常一个事务所做的修改在最终提交之前 对其他事务是不可见的。

  • 在事务正确提交之前，不允许把事务对该数据的改变提供给任何其他事务，
    即在事务正确提交之前，它可能的结果不应该显示给其他事务。

• 事务之间彼此隔离,往往涉及到锁定数据库中行或表

• 多个并发事务之间相互隔离，不能互相干扰。

• 关于事务的隔离性，可能不是特别好理解，这里的并发事务是指两个事务操作了同一份数据的情况；
  而对于并发事务操作同一份数据的隔离性问题，则是要求不能出现脏读、幻读的情况，
  即事务A不能读取事务B还没有提交的数据，或者在事务A读取数据进行更新操作时，不允许事务B率先更新掉这条数据。
  而为了解决这个问题，常用的手段就是加锁了，对于数据库来说就是通过数据库的相关锁机制来保证。

事务隔离级别

• 读未提交（Read uncommitted）

  • Read Uncommitted（读取未提交内容）

• 读提交（read committed）

  • Read Committed（读取提交内容）

• 可重复读（repeatable read）

  • Repeatable Read（可重读）

• 串行化（Serializable）

  • Serializable（可串行化）

问题

• 脏读

• 不可重复读

• 幻读

持久性（Durability）

一旦事务正确提交 ，则其所做的修改就会永久保存在数据库中，不能回滚。
即使在事务提交之后有了其他故障，即使系统崩溃，事务的处理结果也会得到保存，修改的数据也不会丢失。

一旦事务完成，就不能返回

事务完成后所做的改动都会持久化

Durability(架构)

• 架构师、DBA