在本科二年级的时候，有一门课就是设计 CPU，详细的知识点已经记不清楚了，但是记得最开始接触的是单周期 CPU，然后改进成为多周期 CPU，最后课程介绍了流水线 CPU，也让我们亲自设计了一个五级流水线 CPU。从单周期到流水线的演变，CPU 把一个任务切分成了可以并行处理的几个部分，从而提高了整体的处理速度，我就是从那个时候开始认识并行和并发这类问题的。但流水线不是万能的，并行带来不可避免的就是一致性的问题 hazard1。
到了数据库层面，并发下数据一致性也是一个值得细说的话题，下面的讨论基于 MySQL 5.7，InnoDB 引擎。
先来看一个实际问题，一个银行交易系统，有两张表，一张是余额表 user_balance，记录不同用户当前余额。另一张是转账记录表 log，记录用户转账的记录。表的结构如下：
table user_balance
| field | type |
|---|---|
| id | int |
| balance | int |
table log
| field | type |
|---|---|
| id | int |
| from_id | int |
| to_id | int |
| amount | int |
现在要求在一定的并发下，用户余额不能出错，转账记录不能丢，允许有交易失败的情况，要设计这个系统。
假设 ID 为 1 用户向 ID 为 2 的用户转账 100 元，最直觉的设计就是执行如下 SQL：
UPDATE `user_balance`
SET `balance`=`balance`-100
WHERE `id`=1;
UPDATE `user_balance`
SET `balance`=`balance`+100
WHERE `id`=2;
INSERT INTO `log`
(`from_id`, `to_id`, `amount`)
VALUES (1, 2, 100);
这样操作潜在一个问题，数据库或者程序都有可能在执行到一半的时候停止工作，例如是遇到硬盘损坏，网络中断，人为终止等，数据的一致性得不到保障，例如扣款成功而存款失败，转账之后没有记录等。为了解决上面的这个问题，目前关系数据库支持事务（transaction），事务提供了下面的特性2：
- 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
- 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
对于隔离等级3，一般有下面四个等级：
| 隔离级别 | 脏读（Dirty Read） | 不可重复读（NonRepeatable Read） | 幻读（Phantom Read） |
|---|---|---|---|
| 未提交读（Read uncommitted） | 可能 | 可能 | 可能 |
| 已提交读（Read committed） | 不可能 | 可能 | 可能 |
| 可重复读（Repeatable read） | 不可能 | 不可能 | 可能 |
| 可串行化（Serializable ） | 不可能 | 不可能 | 不可能 |
- 未提交读（Read Uncommitted）：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。
- 提交读 (Read Committed）：只能读取到已经提交的数据。
- 可重复读（Repeated Read）：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB 默认级别。在 SQL 标准中，该隔离级别消除了不可重复读，但是还存在幻象读。
- 串行读（Serializable）：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。
对于 MySQL 来说，给刚才的操作加上事务则是：
START TRANSACTION;
UPDATE `user_balance`
SET `balance`=`balance`-100
WHERE `id`=1;
UPDATE `user_balance`
SET `balance`=`balance`+100
WHERE `id`=2;
INSERT INTO `log`
(`from_id`, `to_id`, `amount`)
VALUES (1, 2, 100);
COMMIT;
如果现在再增加一个需求，用户账户的余额不能少于 50 元，上面的 SQL 语句可以改为：
START TRANSACTION;
UPDATE `user_balance`
SET `balance`=`balance`-100
WHERE `id`=1 AND `balance`-100>50;
-- IF FAIL ROLL BACK
UPDATE `user_balance`
SET `balance`=`balance`+100
WHERE `id`=2;
INSERT INTO `log`
(`from_id`, `to_id`, `amount`)
VALUES (1, 2, 100);
COMMIT;
事务是基于锁来实现的，这里的锁特指的是 DBMS 层级实现的锁。当然，事务不一定需要锁，例如 InnoDB 的可重复读则是基于 MVCC4 实现的。根据锁的类型分为共享锁（share lock）和排他锁 （exclusive lock）5。
共享锁又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务 T 对数据 A 加上共享锁后，则其他事务只能对 A 再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。
排他锁又称写锁，如果事务 T 对数据 A 加上排他锁后，则其他事务不能再对 A 加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。
刚才的需求也可以显式使用排他锁实现：
START TRANSACTION;
SELECT *
FROM `user_balance`
WHERE `id`=1
FOR UPDATE;
-- IF LESS THAN 100 THEN ROLL BACK
-- YOU CAN CALCULATE RESULT IN YOUR PROGRAM
SELECT *
FROM `user_balance`
WHERE `id`=2
FOR UPDATE;
UPDATE `user_balance`
SET `balance`=xxx
WHERE `id`=1;
UPDATE `user_balance`
SET `balance`=yyy
WHERE `id`=2;
INSERT INTO `log`
(`from_id`, `to_id`, `amount`)
VALUES (1, 2, 100);
COMMIT;
上面提到的加锁都属于悲观锁6，如果使用乐观锁则不需要基于 DBMS 的锁，只需要新增一个字段判断数据是否已经被修改。
START TRANSACTION;
SELECT *
FROM `user_balance`
WHERE `id`=1;
-- IF LESS THAN 100 THEN ROLL BACK
-- YOU CAN CALCULATE RESULT IN YOUR PROGRAM
SELECT *
FROM `user_balance`
WHERE `id`=2;
UPDATE `user_balance`
SET `balance`=xxx
WHERE `id`=1
AND v=aaa;
-- IF FAIL ROLL BACK
UPDATE `user_balance`
SET `balance`=yyy
WHERE `id`=2
AND v=bbb;
-- IF FAIL ROLL BACK
INSERT INTO `log`
(`from_id`, `to_id`, `amount`)
VALUES (1, 2, 100);
COMMIT;
