基于Spring的事务、分布式事务以及基于redis、zookeeper的分布式锁

一、事务

事务是逻辑上的一组操作，要么都执行，要么都不执行

事务有以下四个特性：

　　原子性：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用

　　一致性：执行事务前后，数据保持一致

　　隔离性：事务不能被其它事务干扰

　　持久性：一个事务被提交之后，它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响

Spring中事务的5个隔离级别：

　　1、Default：跟随数据库的隔离级别

　　2、未提交读：事务可以读取其它事务未提交的数据。会造成脏读。

　　3、提交读：事务可以读其他事务已提交的数据。会造成不可重复读和幻读。

　　4、可重复读：保证事务多次读同一个字段的值相同。会造成幻读。

　　5、序列化执行：事务按序列化逐个执行。完全解决脏读、不可重复读、幻读，但是对性能影响很大，通常不使用。

Spring中事务的7个传播特性：

　　1、外层有其他事务在执行，就运行在外层的事务中，如果外层没有事务，也可以不运行在事务中（就写不写一样）

　　2、外层有其他事务在执行，就运行在外层的事务中，如果外层没有事务，则自己新建一个事务运行

　　3、外层有其他事务在执行，就嵌套运行在外层的事务中，如果外层没有事务，则自己新建一个事务运行（一个事务嵌套另一个事务，外层事务实执行失败则所有事务回滚，内部事务执行失败则只有内部事务回滚）

　　4、外层有其他事务在执行，就新建一个事务运行，不运行在外层事务中（两个事务互不影响）

　　5、标注本方法必须运行在事务中

　　6、标注本方法必须不运行在事务中

　　7、标注该方法不运行在事务中，但如果外层有事务在运行，将事务挂起

二、分布式事务

　　普通事务只运行在一个server上，而当有多个节点需要组合运行事务，需要保证事务的 AICD 特性时，则使用分布式事务。

分布式事务解决方案：

　　1、两阶段提交：协调者加入。向各个节点发送预执行命令（让各个节点启动事务，预执行sql语句，而不提交）----》各个节点执行完后把执行结果发送给协调者----》协调者再根据各个节点执行的结果决定事务是否提交----》把决定下发给各个节点

　　2、三阶段提交：在两阶段的基础上增加询问环节（先询问各个节点是否能正常工作），增加超时时间

　　3、利用消息中间件实现最终一致性。

　　4、利用阿里开源项目seata。

　　5、MySQL XA 次方式性能损耗过大，不做介绍

分析：

　　1、两阶段和三阶段存在很多问题：代码侵入性强，阻塞，容错，单点故障，数据不一致等问题

　　2、利用消息中间件实现最终一致性：能解决两阶段提交的所有问题，但是不能保证消息的时效性。代码0侵入，流程步骤解耦

　　　　实现原理：将事务才分为多个小事务，创建事务表来记录事务，如工行向农行转账：

　　　　　　工行：转账发起，在自己的服务中开启单机事务，保证转账发起扣钱和向数据库事务表中提交一条事务记录；创建定时任务读事务表新增的记录，读到新增的记录后，开启单机事务，保证把事务记录放入消息列队中，并更改事务记录状态为已提交到消息列队。

　　　　　　农行：创建定时任务消费消息列队中的消息，当有新消息时，开启单机事务，保证把工行发过来的消息插入事务表中，并成功消费消息（否则等下次重新消费）；创建定时任务读取事务表中的事务记录，当读取到新记录时，开启单机事务，保证收款账户余额增加，并更新事务表的事务记录状态为已处理。

　　3、利用阿里开源项目seata：去seata官网，拉一个使用与当前框架的demo，根据demo的readme去配置seate server以及seata client即可。seata目前是分布式事务最好的解决方案，一个注解搞定。

三、seata原理（摘抄自官网）

前提

• 基于支持本地 ACID 事务的关系型数据库。
• Java 应用，通过 JDBC 访问数据库。

整体机制

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

• 二阶段：

  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

写隔离

• 一阶段本地事务提交前，需要确保先拿到 全局锁 。
• 拿不到 全局锁 ，不能提交本地事务。
• 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

以一个示例来说明：

两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。

tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 全局锁 ，本地提交释放本地锁。 tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 全局锁 ，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。

tx1 二阶段全局提交，释放 全局锁 。tx2 拿到 全局锁 提交本地事务。

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写 的问题。

总结：

　　seata自己根据生成分布式事务ID维护了一个全局锁，如A，B两个事务同时运行，A先拿到本地锁，做预处理（写undo_log），准备提交数据（此时B事务则等待A事务的本地锁）；A再去seata申请全局锁，如果申请到了就提交数据，没申请到就等待，超时就回滚，全当A事务没来过；A申请到了全局锁，本地数据提交，在本地分支事务表中添加undo_log日志记录（用于回滚），然后释放本地锁（此时B事务就拿到本地锁，开始准备提交，但也要申请到全局锁才能提交；此时其他节点的B事务也不能提交，等全局锁）；A事务全部执行完成，要么回滚要么成功（成功后删除本地分支事务表的undo_log），释放全局锁，这时B事务才能拿到全局锁，正在提交数据。

　　seata回滚是有可能发生脏写：如果一个事务不经过seata，也就不受全局锁控制，直接修改数据，当seata事务回滚的时候，可能会发生脏写。所以用seata维护分布式事务，最好把涉及到seata事务的表的所有事务都交给seata来处理。

四、分布式锁

　　1、利用zookeeper目录树节点的特性来做分布式锁，session创建的节点会随着session销毁，一个节点下创建相同名称的子节点时，zookeeper会为子节点维护一个序列号。当并发时，所有线程都去某个节点下创建session子节点，谁的序列号小，锁就归谁，而没有得到锁的线程就监听自己前面一个序列号，当前一个序列号失效时，在监听的回调方法中，认为已经获得锁做处理

　　2、redis做锁，利用redis的setnx命令特性，setnx只有key不存在时，才能新建成功，所以只有一个线程会成功，其他都会失败，在创建key的时候应该要设置过期时间，避免死锁