现在的互联网,开发一个大型的多人APP,你必定离不开数据库。而如何保证全部人可以高并发的进行读写一直是一个高难度的架构问题,先刨去高并发,保证一致性读写这个问题最经常使用的手段是事务,而实现一个事务的关键点在于锁机制。mysql
今天咱们就来介绍下InnoDB存储引擎如何在高并发下实现锁机制来知足一致性读写的原理和实现。算法
数据库的锁机制是区别于文件系统的一个关键特性。用于管理对共享资源的并发访问。InnoDB会在不少地方使用锁机制,好比操做缓冲池中的数据表、LRU页列表、数据行,为了保证一致性和完整性,须要有锁的机制。sql
对于不一样数据库,锁机制的设计和实现彻底不一样:数据库
数据库中lock和latch均可以称为锁,可是有很大的区别。安全
latch通常称为闩锁,用于保证并发线程操做临界资源的正确性,做用对象是内存数据结构,要求锁定时间很是短,不会检测死锁。在InnoDB引擎中又分为mutex(互斥量)和rwlock(读写锁)。session
lock是用来锁定数据库中的对象,如表、页、行,做用对象是事务,在commit/rollback后释放,会检测死锁。分为行锁、表锁、意向锁。数据结构
咱们下面的锁指的都是lock类锁。架构
InnoDB支持四种锁:并发
当事务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
能够查看到锁的等待信息以及阻塞关系。
经过这三种表可以较为清晰的查看事务和锁的状况,也能够联合查询,在下面的一些场景下咱们会来展现这三个表的内容。
首先咱们来讲下数据库的四种事务隔离级别:
这四种事务隔离级别是指定的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隔离级别时,会使用非锁定的一致性读,可是在这两种隔离级别使用的快找数据定义却不一样:
咱们执行一个示例:
一致性非锁定读 |
||
---|---|---|
时间 | 会话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、一、2三种隔离级别的区别:
#在事务开始前咱们能够分别调整为0、一、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)
在默认的REPEATABLE READ隔离级别时,InnoDB使用的是一致性非锁定读。但有时咱们也须要显示的指定使用一致性锁定读来保证读取操做时对数据进行加锁达到一致性。这要求数据库支持锁定读加锁语句:
这两种锁必须在一个事务中,当事务提交后锁也就释放了,所以务必加上BEGIN, START TRANSACTION或者SET AUTOCOMMIT=0。
咱们在前面隔离级别时也说过SERIALIZABLE隔离级别会对读操做自动加上LOCK IN SHARE MODE指令来加上一个共享锁,所以再也不支持一致性的非锁定读。这也是隔离级别3的一大特性。
因为锁的概念很是重要,这里先讲了锁的概念、锁的类型、锁的信息查看、事务的隔离级别和区别,后面咱们会继续说锁的算法、锁的三种问题和幻读、死锁和锁升级。
喜欢的能够先点赞,我会继续第二篇。