事务的四个特性ACID
- 原子性(Atomictivty)
- 一致性(Consistency)
- 隔离性(Isolation)
- 持久性(Durability)
数据库事务
undolog
回滚日志:保存的是修改之前的值,用于保证原子性,失败了可以进行回滚
redolog
重做日志:保存的是修改之后的值,用于保证持久性,异常宕机时可以通过重做日志就行恢复.
并发控制
常见的并发控制机制有锁,时间戳和MVCC
可以保证一致性和隔离性
分布式事务
原来单机中相对可靠的方法调用变为分布式机器之间的调用
当我们进行网络通信时,通常会有三种结果:成功,失败和超时,无论是
成功还是失败,我们都能得到唯一确定的结果,但超时时不确定的,也进而引发了分布式事务管理的复杂性
2PC
也叫两阶段提交,原来我们单机的事务,现在变成了多机,可以把分布在不同机器的事务的集合看作是一个大事务,多机要么都成功,要么都失败
分布式环境下,每个节点都可以知道自己执行操作后的状态,但无法知道其它节点执行操作后的状态,当一个事务跨越多个系统时,就需要引入一个协调者.
它的大致流程如下
1.协调者说开始了,然后每个机器都开始执行操作
2.每个机器执行完后,并不着急提交,而是先给协调者一个回复
3.协调者收到所有回复时,确定是提交还会回滚,然后通知每台机器进行提交或者回滚
我们可以看到这里有几个问题
1.需要等待所有机器的回复,假设有一台机器执行的很慢,或者回复的时候网络超时了,协调者一致没收到,那么所有机器都会进行阻塞,并且锁住资源
2.协调者也是可能会宕机的,那么每个机器都收不到协调者的命令也会进行阻塞等待,或者协调者只给部分机器发了消息之后就宕机了,那也会造成数据的不一致
3PC
三阶段提交是将两阶段提交里面的投票阶段,也即机器收到协调者命令开始执行本地事务的阶段进行了进一步的拆分
三阶段提交的大致流程如下
1.协调者询问每个机器是否可以执行(注意这个时候是不锁定资源的,而两阶段是一上来就锁定资源开始执行)
2.每个机器给协议这进行回复(当然也会有宕机,或者超时等问题,但由于每个机器其实是没有锁定资源的,所以代价是比较小的)
3.假如协调者收到所有的机器的回复都是可以执行,那么就通知所有机器开始执行
4.每台机器执行完后同样会给协调者一个回复(当然也会有宕机或者超时的问题)
5.每台机器会等待协调者的命令进行提交或者回滚,当然超时也会进行提交或者回滚(因为第一阶段已经确定过了,所以这里是假设没有给回复的机器是执行成功了,只是由于网络超时没有收到信息,所以就擅作主张进行提交了)
我们可以看到三阶段只是把两阶段进行了拆分,第一步不锁定资源,然后宕机或者超时的时候进行自作主张直接进行操作.
这样也可能会造成不一致,因为虽然第一步的时候虽然回复给协调者的是资源已经准备充足,我一定可以执行完毕.但现实的环境往往是不可预测的,可能过了一会就宕机了也不一定,所以三阶段的基础假设是第一步问你你说可以了,那我就假设你后面也是一直可以的.
虽然是一定程度上可以解决超时或者宕机的问题,但这个假设是站不住脚的,很有可能会导致数据的不一致,因为有部分机器自作主张进行了操作
所以面对分布式环境中的不确定性,我们要保证确定性是比较难的.
虽然两阶段提交保证了事务的强一致,但代价也是很大的,会导致很多资源被锁定进行阻塞等待.
Saga
长事务会对一些数据库资源持有较长的一段时间,这会严重地影响其他正常数据库事务的执行.如果一个长事务能够被改写成一系列的相互交错重叠的多个数据库事务,那么这个长事务就是一个Saga
关于Saga协调不同服务的方式有两种
*协同(Choreography)
*编排(Orchestration)
协同
每一个本地事务都会触发一个其他服务中的本地事务的执行,也就是说事务的执行过程是一个流的形式进行的,每一个本地事务最终会向服务的下游发送一个新的事件,即可以是消息队列里面的消息(我们知道如RocketMq里面是有At-least-Once，就是保证消费者至少能收到消息,收不到时它会一直重试),也可以是RPC的请求,只是下游提供的接口需要保证幂等和重入
编排
编排引入了一个协调器,只是不同于两阶段提交,协调器会根据任务的调用情况来决定是否需要调用相应的补偿方案,并且在网络请求出现超时时进行重试,当然这也会导致单点问题
小结:
分布式事务中,一般我们都保证最终一致性而不是强一致性
最终一致性,也就是采用重试和补偿
所以一般也要求我们提供的接口能够保证幂等,而保证幂等我们一般都采用全局唯一Id和状态机机制.
当然追求最终一致性也可以参考前面写的关于Zk的原理介绍