数据库锁，事务特性，脏读，幻读，不可重复度，隔离级别，分布式事务，本地事务的介绍

一、数据库的锁分类

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

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

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

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

行级锁、表级锁和页级锁

行级锁：行级锁分为共享锁和排他锁。行级锁是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 committed，使用写锁，但是读会出现不一致，不可重复度

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

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

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

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

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

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

读提交（Read Committed）

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

可重复度（Repeatable Read）

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

可串行话（Serializable）

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

五、什么是分布式事务

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

六、分布式事务 解决方案：2PC，TCC以及基于消息的最终一致性

消息队列实现最终一致 、
1、订单服务和库存服务完成检查和预留资源。
2、订单服务在本地事务中完成添加订单表记录和添加“减少库存任务消息”。
3、由定时任务根据消息表的记录发送给MQ通知库存服务执行减库存操作。
4、库存服务执行减少库存，并且记录执行消息状态（为避免重复执行消息，在执行减库存之前查询是否执行过此 消息）。
5、库存服务向MQ发送完成减少库存的消息。
6、订单服务接收到完成库存减少的消息后删除原来添加的“减少库存任务消息”。 实现最终事务一致要求：预留资源成功理论上要求正式执行成功，如果执行失败会进行重试，要求业务执行方法实 现幂等。
优点 ： 由MQ按异步的方式协调完成事务，性能较高。 不用实现try/confirm/cancel接口，开发成本比TCC低。
缺点： 此方式基于关系数据库本地事务来实现，会出现频繁读写数据库记录，浪费数据库资源，另外对于高并发操作不是 最佳方案。

七、什么是本地事务

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

transaction begin
insert/delete/update
insert/delete/update
transaction commit/rollback 等
本地事务有这么几个特征:

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

参考https://www.cnblogs.com/kexinxin/p/11620345.html