本地事务
事务的参与者,支持事务的服务器,资源服务器以及事务管理者位于同一台机器时,=
事务的特性ACID
- 原子性(Atomic):数据库数据中的数据操作是不可分割的,执行结果-全部成功即为事务成功,其中某一个操作失败,事务执行失败。
- 一致性(Consistency):数据库中的事务执行不影响数据关系的完整性。
- 隔离性(Isolation):数据中事务之间相互独立。
- 永久性(Durability):数据库事务一旦执行成功,其结果不会被其他因素所影响。
事务未隔离产生的问题
- 脏读
一个事务读取另一个事务未提交的结果; - 不可重复读
一个事务读取另一个事务修改的结果 - 幻读
一个事务第一次读取和第二次执行相同的查询,读到的数据不一致。原因:读取另一个事务提交的结果,导致两次读取的内容不一致。
事务的隔离级别
- READ_UNCOMMITTED:读未提交,什么问题也解决不了
- READ_COMMITTED:读已提交,可以解决脏读问题,其他问题解决不了
- REPETABLE_READ:可重复读,可以解决脏读和不可重复读问题,其他问题解决不了
- SERIALIZABLE:串行化,解决上述三个问题,但是效率最低。
分布式的CAP理论
Consistency
保证所有节点访问是最新的数据。
Availability
保证某一节点故障后,可以响应客户端的请求。
Partion tolearnce
分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务
分布式事务概念
事务的参与者,支持事务的服务器,资源服务器以及事务管理者位于分布式系统不同节点上,解决状态一致性的问题。
举例说明:创建订单服务,创建订单服务包括:库存服务(库存数据库)和订单服务(订单数据库),当两者出现数据不一致情况,需要依赖于分布式事务进行解决
分布式事务解决方案
XA协议
XA协议是Oracle Tuxedo提出的,并交由X/Open组织(心现在更名为Open Group),作为资源管理器和事务管理器的接口标准,目前Oracle,DB2,Sybase,MySQL(Innodb引擎)等数据库厂商提供了对XA的支持,XA提供了两阶段提交的方式来管理分布式事务,XA接口提供了资源管理器和事务管理器的通信标准。
分布式事务模型
应用程序(AP),事务管理器(TM)-交易中间件,资源管理器(RM)-数据库等,通信资源管理器-消息中间件
XA协议的两阶段提交
XA协议的一阶段
用于单体数据库操作
XA协议的二阶段
XA协议的二阶段提交中,TP管理器相当于数据库中间件,TP管理器和数据库之间的通信分为二个阶段:(1)数据库事务的准备(写在redo.log文件中)(2)数据库事务的提交和回滚
XA协议的优缺点
XA协议的优点
XA协议的缺点
TCC解决方案
TCC是Try-Confirm-Cancle,提供是一个事务管理者,作为独立服务出现,非数据库中间件。
Try
业务准备
Confirm
业务提交
Cancle
业务取消
TCC解决方案的优缺点
TCC解决方案的优点
TCC解决方案的缺点
分布式事务中间件
阿里云GTS
对TCC分布式事务的封装,并将其部署在阿里云上,并作为服务提供。
开源应用LCN
LCN
用于解决分布式事务,LCN并不生产事务,是本地事务的协调工,采用柔性事务的处理分布式事务,和TCC处理分布式事务的思想一致,开源免费
LCN
Lock
锁定事务
Confirm
确认事务
Notify
通知执行事务-提交或者回滚
基于消息
Saga协议
Saga的组成
- 每个Saga由一系列sub-transaction Ti 组成
- 每个Ti 都有对应的补偿动作Ci,补偿动作用于撤销Ti造成的结果
- 可以看到,和TCC相比,Saga没有“预留”动作,它的Ti就是直接提交到库。
Saga的执行顺序有两种:
- T1, T2, T3, …, Tn
- T1, T2, …, Tj, Cj,…, C2, C1,其中0 < j < n
Saga定义了两种恢复策略:
- backward recovery,向后恢复,补偿所有已完成的事务,如果任一子事务失败。即上面提到的第二种执行顺序,其中j是发生错误的sub-transaction,这种做法的效果是撤销掉之前所有成功的sub-transation,使得整个Saga的执行结果撤销。
- forward recovery,向前恢复,重试失败的事务,假设每个子事务最终都会成功。适用于必须要成功的场景,执行顺序是类似于这样的:T1, T2, …, Tj(失败), Tj(重试),…, Tn,其中j是发生错误的sub-transaction。该情况下不需要Ci。