ACID
事务（Transaction）是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。事务具有四个特征：
- 原子性 （Atomicity）
只有所有的操作全部成功，整个事务才算是成功。任何一项操作失败都将导致整个事务失败，已经执行的操作将被撤销并回滚
- 一致性 （Consistency）
事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。指对数据的更改必须满足对数据的状态约束。比如对于一个账单系统，账户的贷款余额应和借款余额保持平衡。
这种一致性本质上要求应用层来维护状态一致。而原子性、隔离性和持久性是数据库自身的属性。
- 隔离性 （Isolation）
数据库多个客户端同时访问相同的记录，可能会遇到并发问题。隔离性意味着并发执行的各个事务相互隔离，不能相互交叉。这意味着对于并发事务，其运行结果与串行执行完全相同。
SQL规范中，根据事务满足隔离性的程度将事务分为4个隔离级别：
- 未授权读 （Read Uncommitted）
隔离级别最低。允许脏读，即允许事务访问另一个事务还没有提交的数据。
允许脏写，即无法保证写入的顺序，允许后写入的操作覆盖较早的写入。
- 读-提交 （Read Committed）
不允许脏读和脏写。但允许不可重复读，即一个事务范围内多次查询却返回了不同的数据值。这是由于在查询间隔，被另一个事务修改并提交了。允许更新丢失，即两个事务同时在一个对象上完成“读-修改-写”，可能导致第一个事务的更改值丢失。如两个事务分别将计数值加一。
数据库通常采用行级锁来防止脏写。当事务想修改某个对象时，它必须首先获得该对象的锁，然后一直持有锁直到事务提交或中止。给定时刻，只有一个事务可以拿到特定对象的锁，如果有另一个事务尝试更新同一个对象，必须等到前面的事务完成了提交或中止。
可采取同样的方式防止脏读。即事务也必须获取读锁来读取对象。这种方式当写事务运行时间过长时，会影响读效率。另一种方式是，对于每个待更新的对象，数据库会维护其旧值与事务将要设置的新值两个版本。事务提交之前，所有其他读操作都读取旧值，事务提交之后，才会切换到读取新值。
Oracle, DB2, SQL Server，PostgreSQL的默认隔离级别。
- 可重复读取 （Repeatable Read）
不允许不可重复读。但允许幻读，即在一个事务范围内两次对数据总量的统计不一致。这是由于另一个事务执行了插入操作。
快照隔离级别是解决可重复读取最常见的方法。为了实现快照隔离级别，数据库采用了多版本并发控制（MVCC）保留了对象多个不同的提交版本。在读-提交的两个版本（已提交的旧版本和尚未提交的新版本）基础上，对每个不同的查询单独创建一个快照。
解决更新丢失方法有：
1）数据库原子写操作。如UPDATE counters SET value = value +1 WHERE key = 'foo'。原子写操作通常是采用对读取对象加独占锁的方式来实现的，这样在更新被提交之前不会有其他事务可以读它。或强制所有的原子操作都在单线程上执行。
2）显示加锁，如SELECT FOR UPDATE语法。
3）自动检测更新丢失。数据库可以借助快照级别隔离来检测更新丢失，如果检测到则中止当前事务。PostgreSQL, Oracle和 SQL Server都支持。但MySQL不支持。
- 串行化 （Serializable）
不允许幻读，要求所有事务都被串行执行，不能并发执行。
实现串行化最直接的方式是避免并发，即在一个线程上按顺序方式每次只执行一个事务。Redis采用了这种方式。
- 持久性
一旦某个事务提交，它对数据库所做的更新就必须被永久保存下来，即使存在硬件故障或数据库崩溃。
CAP定理
成熟的ACID模型可保证数据的严格一致性。但对于一个高并发的分布式分布式系统来说，严格一致性可能牺牲掉可用性。由此出现了CAP定理。
CAP定理指出：一个分布式系统不可能同时满足一致性、可用性和分区容错性，最多只能同时满足其中两项。
- 一致性 （Consistency）
同样数据在分布式系统中的多个节点之间是相同的。在分布式系统中，如果一个数据项的更新操作成功后，所有用户都可以读取到其最新的值，这样的系统认为具有强一致性。
- 可用性 （Availability）
系统对于用户的每一个操作请求总是能够在有限的时间内返回结果。
- 分区容错性 （Partition tolerance）
分布式系统在遇到任何网络分区故障的时候，仍能够保证对外提高满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
BASE理论
BASE是对CAP中一致性和可用性权衡的结果。
- 基本可用 （Basically Available）
分布式系统在出现不可预知故障的时候，允许损失部分可用性。包括：响应时间上的损失和功能上的损失。
- 软状态 （Soft state）
允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
- 最终一致性 （Eventually consistent）
上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。
而在实际工程实践中，最终一致性分为5种：
- 因果一致性（Causal consistency）
因果一致性指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。
- 读己之所写（Read your writes）
读己之所写指的是：节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。
- 会话一致性（Session consistency）
会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。
- 单调读一致性（Monotonic read consistency）
单调读一致性指的是：如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。
- 单调写一致性（Monotonic write consistency）
单调写一致性指的是：一个系统要能够保证来自同一个节点的写操作被顺序的执行。
