1. 分布式事务
1.1. 数据库事务
如果一个数据库声称支持事务的操作, 那么该数据库必须要具备以下四个特性 (ACID):
- 原子性 (Atomicity): 事务里的所有操作要么全部做完, 要么都不做。
- 一致性 (Consistency): 数据库要一直处于一致的状态, 事务的运行不会改变数据库原本的一致性约束。
- 隔离性 (Isolation): 并发的事务之间不会互相影响。
- 持久性 (Durability): 持久性是指一旦事务提交后, 它所做的修改将会永久的保存在数据库上, 即使出现宕机也不会丢失。
1.1.1. 隔离性
我们先看看如果不考虑事务的隔离性, 会发生的几种问题:
- 脏读: 在一个事务处理过程里读取了另一个未提交的事务中的数据。
- 不可重复读: 在对于数据库中的某个数据, 一个事务范围内多次查询却返回了不同的数据值, 这是由于在查询间隔, 被另一个事务修改并提交了。
- 虚读 (幻读): 例如事务 T1 对一个表中所有的行的某个数据项做了从 “1” 修改为 “2” 的操作, 这时事务 T2 又对这个表中插入了一行数据项, 而这个数据项的数值还是为 “1” 并且提交给数据库。而操作事务 T1 的用户如果再查看刚刚修改的数据, 会发现还有一行没有修改, 其实这行是从事务 T2 中添加的, 就好像产生幻觉一样, 这就是发生了幻读。
MySQL 数据库为我们提供的四种隔离级别:
- Serializable (串行化): 可避免脏读、不可重复读、幻读的发生。
- Repeatable read (可重复读): 可避免脏读、不可重复读的发生。
- Read committed (读已提交): 可避免脏读的发生。
- Read uncommitted (读未提交): 最低级别, 任何情况都无法保证。
隔离级别的设置只对当前链接有效。
1.2. CAP
- 一致性 (Consistency) : 客户端知道一系列的操作都会同时发生 (生效)
- 可用性 (Availability) : 每个操作都必须以可预期的响应结束
- 分区容错性 (Partition tolerance) : 即使出现单个组件无法可用, 操作依然可以完成
一个 Web 应用至多只能同时支持上面的两个属性。
1.3. BASE
在分布式系统中, 我们往往追求的是可用性, 它的重要程序比一致性要高, 那么如何实现高可用性呢? 前人已经给我们提出来了另外一个理论, 就是 BASE 理论, 它是用来对 CAP 定理进行进一步扩充的。BASE 理论指的是:
- Basically Available – 基本可用
- Soft-state – 软状态 / 柔性事务。 “Soft state” 可以理解为 “无连接” 的, 而 “Hard state” 是 “面向连接” 的
- Eventually Consistency – 最终一致性, 也是 ACID 的最终目的。
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果, 理论的核心思想就是: 我们无法做到强一致, 但每个应用都可以根据自身的业务特点, 采用适当的方式来使系统达到最终一致性(Eventual consistency)。
1.4. 分布式事务
在分布式系统中，要实现分布式事务，无外乎那几种解决方案。
1.4.1. 两阶段提交（2PC）
1.4.2. 三阶段提交（3PC）
1.4.3. TCC
|