如今的互联网，开发一个大型的多人app，你一定离不开数据库。而如何保证所有人能够高并发的进行读写一直是一个高难度的架构问题，先刨去高并发，保证一致性读写这个问题最常用的手段是事务，而实现一个事务的关键点在于锁机制。
今天我们就来介绍下InnoDB存储引擎如何在高并发下实现锁机制来满足一致性读写的原理和实现。
锁
数据库的锁机制是区别于文件系统的一个关键特性。用于管理对共享资源的并发访问。InnoDB会在很多地方使用锁机制，比如操作缓冲池中的数据表、LRU页列表、数据行，为了保证一致性和完整性，需要有锁的机制。
对于不同数据库，锁机制的设计和实现完全不同：
● MyISAM引擎： 表锁设计，并发读没有问题，并发写性能差。
● Microsoft SQL Server: 支持乐观并发和悲观并发，乐观并发下支持行级锁，维持锁的开销大，在行锁数量超过阈值后会升级为表锁。
● InnoDB引擎: 支持行锁，提供一致性的非锁定读。行锁没有额外开销，性能不会下降。
● Oracle：和InnoDB引擎非常类似。
两类锁：lock和latch
数据库中lock和latch都可以称为锁，但是有很大的区别。
latch一般称为闩锁，用于保证并发线程操作临界资源的正确性，作用对象是内存数据结构，要求锁定时间非常短，不会检测死锁。在InnoDB引擎中又分为mutex（互斥量）和rwlock（读写锁）。
lock是用来锁定数据库中的对象，如表、页、行，作用对象是事务，在commit/rollback后释放，会检测死锁。分为行锁、表锁、意向锁。
我们下面的锁指的都是lock类锁。
四种锁类型
InnoDB支持四种锁：
● 共享锁（S Lock）：允许事务读一行数据
● 排他锁（X Lock）：允许事务删除或更新一行数据
● 意向共享锁（Intention S Lock）：事务想要获得一张表中某几行的共享锁
● 意向排他锁（Intention X Lock）：事务想要获得一张表中某几行的排他锁
当事务T1获取了行r的共享锁，由于读取不会改变行数据，因此事务T2也可以直接获得行r的共享锁，此时称为锁兼容（Lock Compatible）。
而当事务T3想要获取行r的排他锁进行修改数据时，就需要等待T1/T2释放行共享锁，此时称为锁不兼容。
S锁和X锁都是行锁，而IS锁和IX锁都为意向锁，属于表锁。意向锁的设计是为了在一个事务中揭示下一行将被请求的锁类型，即在表锁的更细粒度进行锁定。由于InnoDB支持表锁，因此意向锁不会阻塞除全表扫描外的任何请求。
锁的兼容性：
| IS | IX | S | X | |
| IS | 兼容 | 兼容 | 兼容 | 不兼容 |
| IX | 兼容 | 兼容 | 不兼容 | 不兼容 |
| S | 兼容 | 不兼容 | 兼容 | 不兼容 |
| X | 不兼容 | 不兼容 | 不兼容 | 不兼容 |
存储事务和锁信息的三张表
我们可以通过show engine innodb status命令在事务部分查看当前锁请求的信息。
从InnoDB1.0开始，在INFORMATION_SCHEMA架构下添加了INNODB_TRX（transaction事务表）、INNODB_LOCKS（锁表）、INNODB_LOCK_WAITS（锁等待表），通过这三张表，可以让我们实时监控当前事务并分析可能存在的表问题。
三个表的定义分别为：
INNODB_TRX | |
|---|---|
| trx_id | InnoDB存储引擎内部唯一的事务ID |
| trx_state | 当前事务的状态 |
| trx_started | 事务的开始时间 |
| trx_requested_lock_id | 等待事务的锁IDC，当状态不为LOCK WAIT时为NULL |
| trx_wait_started | 事务等待开始的时间 |
| trx_weight | 事务的权重，反映一个事务修改和锁定的行数。当需要回滚时，选择该值最小的事务进行回滚 |
| trx_mysql_thread_id | MySQL的线程ID，show processlist显示的结果 |
| trx_query | 事务运行的SQL语句 |
INNODB_LOCKS | |
|---|---|
| lock_id | 锁ID |
| lock_trx_id | 事务ID |
| lock_mode | 锁的模式 |
| lock_type | 锁的类型，表锁或行锁 |
| lock_table | 要加锁的表 |
| lock_index | 锁住的索引 |
| lock_space | 锁对象的space id |
| lock_page | 事务锁定页的数量，表锁时为NULL |
| lock_rec | 事务锁定行的数量，表锁时为NULL |
| lock_data | 事务锁定记录的主键值，表锁时为NULL |
INNODB_LOCK_WAITS | |
|---|---|
| requesting_trx_id | 申请锁资源的事务ID |
| requesting_lock_id | 申请的锁的ID |
| blocking_trx_id | 阻塞的事务ID |
| blocking_lock_id | 阻塞的锁的ID |
通过INNODB_TRX我们可以看到所有的事务，以及事务是否被阻塞，阻塞的锁ID是什么。
之后，通过INNODB_LOCKS查看所有的锁信息。
之后，通过INNODB_LOCK_WAITS可以查看到锁的等待信息以及阻塞关系。
通过这三种表能够较为清晰的查看事务和锁的情况，也可以联合查询，在下面的一些场景下我们会来展示这三个表的内容。
隔离级别
首先我们来说下数据库的四种事务隔离级别：
● READ UNCOMMITTED（0）: 浏览访问级别，存在脏读、不可重复读、幻读
● READ COMMITTED（1）: 游标稳定级别，存在不可重复度、幻读
● REPEATABLE READ（2）: 存在幻读
● SERIALIZABLE（3）: 隔离级别，保证事务安全，但完全串行，性能低
这四种事务隔离级别是指定的SQL标准，InnoDB默认的隔离级别是REAPEATABLE READ，但与其他数据库不同的时，它同时使用了Next-Key-Lock锁的算法，能够避免幻读的产生，因此能够完全满足事务的隔离性要求，即达到SERIALIZABLE隔离级别。
隔离级别越低，事务请求的锁越少或持锁时间越短，因此大部分数据库的默认隔离级别为READ COMMITED。但是有相关的分析也指出，隔离级别的性能开销几乎一样，因此用户无须通过调整隔离级别来提高性能。
查看和修改事务隔离级别的命令:
mysql> select @@session.tx_isolation; +------------------------+ | @@session.tx_isolation | +------------------------+ | REPEATABLE-READ | +------------------------+ 1 row in set (0.00 sec) mysql> set session transaction isolation level SERIALIZABLE; Query OK, 0 rows affected (0.00 sec)
示例中修改了本次会话的事务隔离级别，如果需要修改全局参数，可以替换session为global。如果想要永久修改，需要修改配置文件：
[mysqld] transaction-isolation = READ-COMMITED
在SERIALIZABLE的事务隔离级别，InnoDB会对每个SELECT语句后自动加上LOCK IN SHARE MODE，来对读操作加上一个共享锁，因此不再支持一致性的非锁定读。
由于InnoDB在REPEATABLE READ隔离级别就可以达到SERIALIZABLE，因此一般不用使用最高隔离级别。
一致性非锁定读和多版本并发控制
一致性非锁定读（consistent nonlocking read）是指InnoDB通过行多版本控制（Multi Version Concurrency Control, MVCC）的方法来读取当前执行时间数据库中行的数据。
即如果读取的行正在执行变更操作，这时读取不会等待行锁的释放，而是会读取行的一个快照数据。快照是指该行的一个历史数据，通过undo操作来完成。这种方式极大提高了数据库的并发性，这也是InnoDB的默认设置。
快照是当前行的一个历史版本，但可能存在多个版本，行数据存在多个快照数据，这种技术成为行多版本技术，由此带来的并发控制，称为多版本并发控制（MVCC）。InnoDB在READ COMMITED 和 REPEATABLE READ隔离级别时，会使用非锁定的一致性读，但是在这两种隔离级别使用的快找数据定义却不同：
● READ COMMITED: 总是读取最新一份快照
● REPEATABLE READ: 总是读取事务开始时的行数据版本
我们执行一个示例：
一致性非锁定读 | ||
|---|---|---|
| 时间 | 会话A | 会话B |
| 1 | BEGIN | |
| 2 | select * from z where a = 3; | |
| 3 | BEGIN | |
| 4 | update z set b=2 where a=3; | |
| 5 | select * from z where a = 3; | |
| 6 | COMMIT; | |
| 7 | select * from z where a = 3; | |
| 8 | COMMIT; | |
在这个例子中我们可以清晰的看到0、1、2三种隔离级别的区别：
#在事务开始前我们可以分别调整为0、1、2三种隔离级别，来查看不同的输出 mysql> set session transaction isolation level READ UNCOMMITTED; Query OK, 0 rows affected (0.00 sec) mysql> select @@tx_isolation; +------------------+ | @@tx_isolation | +------------------+ | READ-UNCOMMITTED | +------------------+ 1 row in set (0.00 sec) # A会话：T1事务 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from z where a = 3; +---+------+ | a | b | +---+------+ | 3 | 1 | +---+------+ 1 row in set (0.00 sec) # B会话：T2事务 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> update z set b=2 where a=3; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 # A会话：T1事务，如果此时隔离级别是READ-UNCOMMITTED，因为此刻事务2可能会回滚，所以出现了脏读 mysql> select * from z where a=3; +---+------+ | a | b | +---+------+ | 3 | 2 | +---+------+ 1 row in set (0.00 sec) # A会话：T1事务，如果此时隔离级别是大于READ-UNCOMMITTED的更高级别 mysql> select * from z where a=3; +---+------+ | a | b | +---+------+ | 3 | 1 | +---+------+ 1 row in set (0.00 sec) # B会话：T2事务 mysql> commit; Query OK, 0 rows affected (0.00 sec) # A会话：T1事务，如果此时隔离级别是READ-COMMITTED，因为数据和事务开始时读取的出现了不一致，因此称为不可重复读，能够读到其他事务的结果，违反了事务的隔离性 mysql> select * from z where a=3; +---+------+ | a | b | +---+------+ | 3 | 2 | +---+------+ 1 row in set (0.00 sec) # A会话：T1事务，如果此时隔离级别是大于READ-COMMITTED的更高级别 mysql> select * from z where a=3; +---+------+ | a | b | +---+------+ | 3 | 1 | +---+------+ 1 row in set (0.00 sec) # A会话：T1事务 mysql> commit; Query OK, 0 rows affected (0.00 sec)
一致性锁定读和SERIALIZABLE隔离
在默认的REPEATABLE READ隔离级别时，InnoDB使用的是一致性非锁定读。但有时我们也需要显示的指定使用一致性锁定读来保证读取操作时对数据进行加锁达到一致性。这要求数据库支持锁定读加锁语句：
● select ... for update: 读取时对行记录加X锁
● select ... lock in share mode：读取时对行记录加一个S锁
这两种锁必须在一个事务中，当事务提交后锁也就释放了，因此务必加上BEGIN, START TRANSACTION或者SET AUTOCOMMIT=0。
我们在前面隔离级别时也说过SERIALIZABLE隔离级别会对读操作自动加上LOCK IN SHARE MODE指令来加上一个共享锁，因此不再支持一致性的非锁定读。这也是隔离级别3的一大特性。
总结
由于锁的概念非常重要，这里先讲了锁的概念、锁的类型、锁的信息查看、事务的隔离级别和区别，后面我们会继续说锁的算法、锁的三种问题和幻读、死锁和锁升级。
推荐学习：MySQL教程
