分布式事务概述
目录
前言
分布式事务是分布式系统中经常会使用到的技术，当我们的系统存在跨库事务、分库分表、微服务化这些场景我们将需要处理分布式事务，本文将围绕事务相关的概念介绍，以及通过实例来对实现分布式事务手段进行深入讲解。
一、事务
事务：就是为了使得一些更新操作要么都成功，要么都失败
事务的ACID特性
- 原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。
- 一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是300，不会存在我账上钱加了，你账上钱没扣的中间状态。
- 隔离性（Isolation），指的是多个事务并发执行的时候不会互相干扰，即一个事务内部的数据对于其他事务来说是隔离的。
- 持久性（Durability），指的是一个事务完成了之后数据就被永远保存下来，之后的其他操作或故障都不会对事务的结果产生影响。
二、分布式事务
分布式事务顾名思义就是要在分布式系统中实现事务，它其实是由多个本地事务组合而成。
2.1、理论基础
CAP定理：分布式系统设计理论
一致性(Consistency)
数据更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态
可用性(Availability)
系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果
分区容错性(Partition tolerance)
分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务
为什么要在一致性（C）和可用性（A）之间进行取舍？
如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的
如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。
BASE定理
CAP理论中AP方案的延伸，对于C我们采用的方式和策略就是保证最终一致性
Basically Available（基本可用）
分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用
Soft state（软状态）
指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性
Eventually consistent（最终一致性）
强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态
2.2、解决方案
强一致性分布式事务解决方案
典型方案
DTP模型（全局事务模型
DTP模型是X/Open组织定义的一套分布式事务标准，这套标准主要定义了实现分布式事务的规范和API，具体的实现则交给相应的厂商来实现。
2PC模型（二阶段提交模型）
2PC模型是指两阶段提交协议模型，这种模型将整个事务流程分为Prepare阶段和Commit阶段。2PC中的2指的是两个阶段，P是指Prepare，即准备，C是指Commit，即提交。
3PC模型（三阶段提交模型）
3PC模型是指三阶段提交模型，是在2PC模型的基础上改进的版本。3PC模型把2PC模型中的Prepare阶段一分为二，最终形成3个阶段：CanCommit阶段、PreCommit阶段和doCommit或者doRollback阶段。
最终一致性分布式事务解决方案
典型方案
TCC解决方案
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作，在TCC分布式事务解决方案中，需要实现的服务模式包括TCC操作、幂等操作、可补偿操作和可查询操作，只有实现了这些操作才能做到事务补偿。
可靠消息最终一致性解决方案
可靠消息最终一致性分布式事务解决方案指的是事务的发起方执行完本地事务之后，发出一条消息，事务的参与方，也就是消息的消费者一定能够接收到这条消息并处理成功。这个方案强调的是只要事务发起方将消息发送给事务参与方，事务参与方就一定能够执行成功，事务最终达到一致的状态。
最大努力通知型解决方案
最大努力通知型分布式事务解决方案在执行的过程中，允许丢失消息，但需要业务主动方提供事务状态查询接口，以便业务被动方主动调用并恢复丢失的业务。
总结
本文概述性的总结归纳了分布式事务的基础理论以及常见的解决方案，下一篇将会对分布式事务解决方案进行案例讲解。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
