事务:就是被绑定在一起作为一个逻辑工作单元的SQL语句分组,如果任何一个语句操作失败那么整个操作就被失败,以后操作就会回滚到操作前状态,或者是上有个节点。为了确保要么执行,要么不执行,就可以使用事务。要将有组语句作为事务考虑,就需要通过ACID测试,即原子性,一致性,隔离性和持久性。
锁:在所以的DBMS中,锁是实现事务的关键,锁可以保证事务的完整性和并发性。与现实生活中锁一样,它可以使某些数据的拥有者,在某段时间内不能使用某些数据或数据结构。当然锁还分级别的。
扁平化事务:在扁平事务中,所有的操作都在同一层次,这也是平时使用最多的事务,主要限制是不能提交或回滚事务的某一部分,要么都成功要么都回滚。 带保存点的扁平事务:解决了扁平事务的弊端,它允许事务在执行过程中回滚到较早的状态而不是全部回滚,通过在事务中插入保存点,当操作失败后可以选择回滚到最近的保存点处。
链事务:可看做第二种事务的变种,它在事务提交时,会将必要的上下文隐式传递给下一个事务,当事务失败时,可以回滚到最近的事务,不过链事务只能回滚到最近的保存点,而带保存点的扁平化事务是可以回滚到任意一个保存点。
嵌套事务:由顶层事务和子事务构成,类似于树的结构,一般顶层事务负责逻辑处理,子事务负责具体的工作,子事务可以提交,但真正的提交要等到顶层事务的提交,如果顶层事务回滚,那么所有的子事务都将回滚。 分布式事务:在分布式环境中的扁平化事务。
常用的分布式事务解决方案:
(1) XA规范,是保证强一致性的刚性事务,实现方式有两段式提交(2PC)和三段式提交(3PC),2PC需要一个事务协调者来保证事务的参与者都完成了第一阶段的准备工作,如果协调者收到了所有的参与者都准备好的消息,就会通知所有的事务执行第二阶段的提交,一般场景下两段式提交已经能很好的解决分布式事务了。然而两阶段在即使只有一个进程发生故障时,也会导致整个系统存在较长时间的阻塞。三段式提交通过增加pre-commit阶段来减少两段式提交提到的系统阻塞时间,三段式提交很少在实际中使用,简单了解就行了。
(2) TCC:是满足最终一致性的柔性事务方案。TCC采用补偿机制,核心的思想是对每一个操作都要注册对应的确认和补偿操作,分为三个阶段,try阶段主要对业务系统进行检测及资源预留,confirm阶段对业务系统进行确认提交,cancel阶段是对业务执行错误,执行回滚释放预留的资源。
(3) 消息一致性方案:基本思路是将本地操作和发送消息封装在一个事务中,保证本地的操作和消息发送要么都成功,要么都失败。下游应用订阅消息,收到消息后执行对应的操作。
(4)GTS:阿里云的全局事务服务,对应的开源版本是Fescar,Fescar基于两段式提交进行改良,剥离了分布式事务方案对数据库在协议支持上的要求,使用Fescar的前提是分支事务中涉及的资源必须支持ACID事务的关系型数据库,分支的提交和回滚都依赖于本地事务来保障。了解即可。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。