数据库事务

一、数据库的锁分类

锁分类

按锁的粒度划分：表级锁、行级锁、页级锁

按锁级别划分：共享锁、排它锁、意向锁

按加锁方式划分：自动锁、显示锁

按使用方式划分：乐观锁、悲观锁

行级锁、表级锁和页级锁

**行级锁：**行级锁分为共享锁和排他锁。行级锁是MySQL中锁定粒度最细的锁。InnoDB引擎支持行级锁和表级锁，只有在通过索引条件检索数据的时候，才使用行级锁，否就使用表级锁。行级锁开销大，加锁慢，锁定粒度最小，发生锁冲突的概率最低，并发度最高。

**表级锁：**表级锁分为表共享锁和表独占锁。表级锁开销小，加锁快，锁定粒度大，发生锁冲突最高，并发度最低

**页级锁：**页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折中的页级，一次锁定相邻的一组记录。BDB支持页级锁。开销和加锁时间界于表锁和行锁之间；会出现死锁。锁定粒度界于表锁和行锁之间，并发度一般。

二、MySQL中排它锁和共享锁

排它锁（exclusive lock）

排他锁又叫写锁，如果事务T对A加上排它锁，则其他事务都不能对A加任何类型的锁。获准排它锁的事务既能读数据，又能写数据

共享锁（share lock）

共享锁又叫读锁，如果事务T对A加上共享锁，则其他事务只能对A再加共享锁，不能加其他锁。共享锁的事务只能读数据，不能写数据。

三、 事务的四大特性是：

** 原子性（Atomicity）：**事务中所有操作是不可再分割的原子单位。事务中所有操作要么全部执行成功，要么全部执行失败。

** 一致性（Consistency）：**事务执行后，数据库状态与其它业务规则保持一致。如转账业务，无论事务执行成功与否，参与转账的两个账号余额之和应该是不变的。

** 隔离性（Isolation）：**隔离性是指在并发操作中，不同事务之间应该隔离开来，使每个并发中的事务不会相互干扰。

** 持久性（Durability）：**一旦事务提交成功，事务中所有的数据操作都必须被持久化到数据库中，即使提交事务后，数据库马上崩溃，在数据库重启时，也必须能保证通过某种机制恢复数据

四、什么是脏读，不可重复度，幻读

脏读 : 一个事务读取到了另一个事务未提交的数据操作结果。可能造成所有数据一起回滚！

不可重复读 ： 事务 T1 读取某一数据后，事务 T2 对其做了修改，当事务 T1 再次读该数据时得到与前一次不同的 值。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

幻读 : 事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据或者缺少了第一次查 询中出现的数据（并不要求两次查询的 SQL 语句相同）。这是因为在两次查询过程中有另外一个事务插入数据造 成的

五、事务的隔离级别有哪些

Read Uncommitted，读写均不使用锁，数据的一致性最差，也会出现许多逻辑错误。

读不提交，造成脏读（Read Uncommitted）

一个事务中的读操作可能读到另一个事务中未提交修改的数据，如果事务发生回滚就可能造成错误。

例子：A打100块给B，B看账户，这是两个操作，针对同一个数据库，两个事物，如果B读到了A事务中的100块，认为钱打过来了，但是A的事务最后回滚了，造成损失。

避免这些事情的发生就需要我们在写操作的时候加锁，使读写分离，保证读数据的时候，数据不被修改，写数据的时候，数据不被读取。从而保证写的同时不能被另个事务写和读。

Read committed，使用写锁，但是读会出现不一致，不可重复度

读提交（Read Committed）

我们加了写锁，就可以保证不出现脏读，也就是保证读的都是提交之后的数据，但是会造成不可重读，即读的时候不加锁，一个读的事务过程中，如果读取数据两次，在两次之间有写事务修改了数据，将会导致两次读取的结果不一致，从而导致逻辑错误。

Repeatable Read，使用读锁和写锁，解决不可重复读的问题，但会有幻读

可重复度（Repeatable Read）

解决不可重复读问题，一个事务中如果有多次读取操作，读取结果需要一致（指的是固定一条数据的一致，幻读指的是查询出的数量不一致）。 这就牵涉到事务中是否加读锁，并且读操作加锁后是否在事务commit之前持有锁的问题，如果不加读锁，必然出现不可重复读，如果加锁读完立即释放，不持有，那么就可能在其他事务中被修改，若其他事务已经执行完成，此时该事务中再次读取就会出现不可重复读

Serializable，使用事务串行化调度，避免出现因为插入数据没法加锁导致的不一致的情况

可串行话（Serializable）

解决幻读问题，在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。

六、什么是本地事务

本地事务也称为数据库事务或传统事务（相对于分布式事务而言）。它的执行模式就是常见的：

transaction begin
insert/delete/update
insert/delete/update
transaction commit/rollback 等

本地事务有这么几个特征:

1、一次事务只连接一个支持事务的数据库（一般来说都是关系型数据库）
2、事务的执行结果保证ACID
3、会用到数据库锁

七、什么是分布式事务

分布式事务：就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

分布式事务的产生的原因

1、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表；简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

2、应用SOA化

所谓的SOA化：就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

分布式事务的应用场景

1、支付：

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

2、在线下单：

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

常见的分布式事务解决方案

1、基于XA协议的两阶段提交

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。