目录
1、概念
分布式事务分类
刚性分布式事务:强一致性、XA模型
柔性分布式事务:最终一致性、cap、base理论
ACID,关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区:
- Atomicity原子性:一个事务中所有操作都必须全部完成,要么全部不完成。
- Consistency一致性:在事务开始或结束时,数据库应该在一致状态。
- Isolation隔离层:事务将假定只有它自己在操作数据库,彼此不知晓。
- Durability持久化:一旦事务完成,就不能返回。
BASE,BASE模型反ACID模型,完全不同ACID模型,牺牲高一致性,获得可用性或可靠性:
- Basically Available 基本可用:支持分区失败(e.g. sharding碎片划分数据库)
- Soft state 软状态:状态可以有一段时间不同步,异步。
- Eventually consistent 最终一致:最终数据是一致的就可以了,而不是时时高一致。
CAP,分布式领域CAP理论:
- Consistency(一致性):数据一致更新,所有数据变动都是同步的
- Availability(可用性):好的响应性能
- Partition tolerance(分区容忍性):可靠性
定理:任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
2、分布式事务实现方式
2.1、2PC
跨数据库两段提交事务:2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,JavaEE中的JTA事务可以支持2PC。因为2PC是反模式,尽量不要使用2PC,使用BASE来回避。
第一阶段
- 提交事务请求:协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应。
- 执行事务:各个参与者节点执行事务操作。并将Undo和Redo信息记入事务日志中。
- 各参与者向协调者反馈事务询问的响应:如果参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。
第二阶段
- 执行事务提交:假如协调者从所有参与者获得的响应都为Yes,那么就执行事务提交,协调者向所有参与者节点发出Commit请求
- 参与者提交事务:参与者接收到Commit请求后,会正式执行事务提交操作,并在完成提交之后释放在整个事务执行期间占用的事务资源,并向协调者发送Ack消息
- 完成事务:协调者接收到所有参与者反馈的Ack消息后,完成事务
中断事务
假如任何一个参与者反馈给协调者No响应,或者在等待超时之后,协调者没有收到所有参与者的响应,那么就会中断事务
- 发送回滚请求:协调者向所有参与者发送Rollback请求
- 事务回滚:参与者接收到Rollback请求后,会利用其在阶段一中记录的Undo信息来执行事务回滚操作,完成回滚之后释放在整个事务执行期间占用的资源,并向协调者发送Ack消息,协调者接收到所有的参与者反馈的Ack消息后,完成事务中断
优缺点
二阶段提交协议的整个过程就是这样,这种先请求后提交的方式,能够保证所有节点在进行事务处理过程中保持原子性,进行统一的提交或回滚,可以看作是一个强一致性的算法。那我们就来思考一下,它有哪些优点,以及会带来什么问题。
- 优点:简单好用,实现方便。
- 缺点:同步阻塞,单点问题,还是会有数据不一致的情况出现。
- 同步阻塞:在二阶段提交事务的过程中,所有参与该事务操作的逻辑都处于阻塞状态,各个参与者在等待其他参与者的响应过程中,无法做其他的操作。
- 单点问题:在二阶段提交协议中,协调者这个角色是很重要的,一旦协调者挂掉,将导致整个提交流程无法运转,若是在第二阶段协调者挂掉,参与者将一直处于锁定事务资源的状态,无法继续完成事务操作。
- 数据不一致:若是在第二阶段,协调者在向所有参与者发送commit请求时,由于局部网络的故障,只有部分参与者受到commit请求,提交事务,这样没有受到commit请求的就没有提交事务,出现了数据不一致的情况。
2.2、Paxos
https://blog.csdn.net/Dopamy_BusyMonkey/article/details/107709465
2.3、Raft
https://blog.csdn.net/Dopamy_BusyMonkey/article/details/107711800
2.4、Zab
https://blog.csdn.net/Dopamy_BusyMonkey/article/details/90612899
3、分布式事务解决方案
3.1、TCC(LCN框架)
(Try-Confirm-Cancel)补偿模式(最终一致性)TCC模型完全交由业务实现、每个子业务都需要实现TCC接口:try:尝试执行业务,完成所有业务检查、预留必要的业务资源;confirm:真正执行业务、不再做业务检查;cancel:释放try阶段预留的业务资源。
- 该模式对代码的嵌入性高,要求每个业务需要写三种步骤的操作。
- 该模式对有无本地事务控制都可以支持使用面广。
- 数据一致性控制几乎完全由开发者控制,对业务开发难度要求高。
3.2、LCN(LCN框架)
LCN模式是通过代理Connection的方式实现对本地事务的操作,然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作,该代理的连接将由LCN连接池管理。
该模式对代码的嵌入性为低。
该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。
该模式下的事务提交与回滚是由本地事务方控制,对于数据一致性上有较高的保障。
- 该模式缺陷在于代理的连接需要随事务发起方一共释放连接,增加了连接占用的时间。
3.3、TXC(LCN框架)
TXC模式命名来源于淘宝,实现原理是在执行SQL之前,先查询SQL的影响数据,然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库,目前锁实现依赖redis分布式锁控制。
- 该模式同样对代码的嵌入性低。
- 该模式仅限于对支持SQL方式的模块支持。
- 该模式由于每次执行SQL之前需要先查询影响数据,因此相比LCN模式消耗资源与时间要多。
- 该模式不会占用数据库的连接资源。
DTP模型(全局事务、强一致性)
全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务,需要三种角色:
- AP:Application 应用系统 ,它就是我们开发的业务系统,在我们开发的过程中,可以使用资源管理器提供的事务接口来实现分布式事务。
- TM:Transaction Manager 事务管理器,分布式事务的实现由事务管理器来完成,它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器,通过它们提供的XA接口来同一调度这些资源管理器,以实现分布式事务。DTP只是一套实现分布式事务的规范,并没有定义具体如何实现分布式事务,TM可以采用2PC、3PC、Paxos等协议实现分布式事务。
- RM:Resource Manager 资源管理器,能够提供数据服务的对象都可以是资源管理器,比如:数据库、消息中间件、缓存等。大部分场景下,数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力,它们通过XA接口,将本数据库的提交、回滚等能力提供给事务管理器调用,以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口,用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范,RM具体的实现是由数据库厂商来完成的。
有没有基于DTP模型的分布式事务中间件?
DTP模型有啥优缺点?
3.4、基于可靠消息服务的分布式事务
rocketmq
最大努力通知(定期校对)