分布式事务处理入门

抢锁
N
捞取初始数 据进行恢复
Start_span
结束
End_span
expire
容量分析
基本原则
• 前提：调用异常占比极少
• 只记结果数据，不记过程数据
最终结果
• 主事务：1次insert，1次update。
• 分支事务：1次insert。 • 查询数量：只在调用异常时使用，量非常少
分布式事务实现-正常调用
发起者
1.开启本地事务 2.注册一个远程事务（主事务）
参与者
XTS
4.调用参与者 5.加入分支事务
3.Business_activity增加一条的I的记录
7.完成参与者业务 8.本地事务提交 8.XTS根据本地事务结果commit/rollback
6.Business_action增加一条记录
10.循环第2阶段commit/rollback
分布式定时任务
mutex_task字段说明
字段 id 说明
task_name lock_host
lock_status gmt_last_lock
任务名称 被哪个机器锁了
锁状态 上次锁的时间，如果 跟当前时间差很多， 有权忽略 lock_status 当前时间减去 start_span就是查询 的开始时间 当前时间减去 end_span就是查询 的结束时间 锁的超时时间 Y
1.银行支付完成 2.开启本地事务 3.注册一个远程事务（主事务）
account
XTS
如果发生回 滚，支付能 发起重试
4.增加余额并冻结 5.加入分支事务
6.完成充值，并冻结预处理
7.本地事务提交 8.XTS根据本地事务结果commit/rollback 第2阶段commit/rollback
典型业务场景-提现
Thanks
Q&A
propagation context gmt_create gmt_modifie d
主事务状态机
NULL
初始化状态：发起 方注册主事务。 未知状态：是由协 调者会查时发起者 给的结果，理论上 不应该出现，出现 了可能需要人工介 入了。
初始化
确认提交状态
确认回滚状态
未知状态
提交状态：发起方 本地事务提交了， 事务同步器提交到 服务端
发起者在本地事务外开启。
应用可以选择在合适的时候绑定本地事务。 应用需要确保事务一定会提交或者回滚。
需要实现回查接口，数据要确保可重复读。
事务改造-参与者
在业务过程中需要显式的调用客户端把自己加入 到分支事务中。 需要实现xts提供的二阶段提交/回滚服务。 事务状态需要保证幂等性（比如xts发起提交的时 候，此时数据已经提交，也需要返回提交成功）
优缺点
一定程度降低了系统处理分布式事务一致性带来的复杂度， 提供了最终一致性的保障。
整个设计是存储无关的，底层数据库可以采用任何一种数 据库。 对性能的影响，因为是在本地事务重开启了分布式事务， 单个事务的操作时间会很大程度受rpc响应时间影响，如 果rpc时间过长，会影响单机的吞吐量。
9.捞取Business_action记录 11.更新Business_activity状态
12.根据配置结果通知
分布式事务实现-恢复流程
发起者 参与者 XTS
2.查询事务状态
1.Business_activity捞取I，U的记录
4. commit/rollback
3.根据事务id查询Business_action
分布式事务方案
大纲
基本原理 服务端设计 应用改造方案 典型业务场景 接入方式
数据一致性
数据一致性。
关联数据之间的逻辑关系是否正确和完整。
一致性分类。
强一致 弱一致性
最终一致性
分布式事务
分布式事务就是指事务的参与者、支持事务的服务器、 资源服务器以及事务管理器分别位于不同的分布式系 统的不同节点之上。 产生原因
主事务管理器 定 时 任 务 分支事务管理器
发起者
注册分支事务 提交 回滚
参与者
同库和异库分布式事务
同库：主事务和业务流水在一个db中，占用业务 系统的db容量，但是减少了主事务注册的远程调 用，性能有优势，对应用来说改动相对比较大。 异库：主事务在xts系统中，所有的分布式事务都 需要xts来主控，可能存在单点问题，比如db挂掉， 应用挂掉。
transcore
异步提现 开启本地事务
payment
account
XTS
事务失败， payment能 自动恢复
开启分布式事务 转账 加入分布式事务
转到中间账户 XTS根据本地事务结果commit/rollback
银行提现
大纲
基本原理 服务端设计 应用改造方案 典型业务场景 接入方式
发起者配置
参与者接入
三、新增一个表，存放分布式事务相关的信息。
一阶段的时候把数据单独存起来，业务处理时要考虑到这个新增 的表中数据。 二阶段提交时直接把数据移到主流水中，回滚则直接删除数据。 注意和主流水在一个事务里。
大纲
基本原理 服务端设计 应用改造方案 典型业务场景 接入方式
典型业务场景-充值
payment
回滚状态：发起方 本地事务回滚了， 事务同步器回滚
定时恢复
daemon
捞取主事务的时候 需要注意时间段， 不能跨度太长导致 db压力。 查询事务状态的时 候只有在提交或者 回滚的时候才需要 恢复。
捞取主事务状 态为I的记录
loop
查询发起者事 务状态
wk.baidu.com
根据主事务id 获取分支事务 提交/回滚分 支事务
几个注意点
1.事务id传递有两种方式，一是在服务接口里直接传递，二是在
dubbo上下文里获取。 2.由于同一笔业务可能发起多次调用，发起者应做好记录，防止在查
询的时候查询不到流水。
3.context中可以存放业务流水，如果根据事务id无法查询到数据，可 以通过业务流水查询状态。 4.参与者要做好状态控制，支持多次提交和回滚。 5.参与者要做好请求流水的幂等控制，xts只能保证单个事务的最终一 致性，业务上的控制需要应用自行控制。
6.根据配置结果通知
5.更新Business_activity状态
大纲
基本原理 服务端设计 应用改造方案 典型业务场景 接入方式
事务改造-发起者
发起者在本地事务内开启。
只要负责开启事务，客户端会自动在本地事务管理器 中注册事务同步器。 本地事务提交时，由事务同步器自动通知服务端进行 事务回滚或者提交。
数据库分库分表 应用SOA化
常见方案
基于XA协议的两阶段提交
消息事务+最终一致性
TCC编程模式
两阶段提交基本模型
事务协调者
1.准备 2.已准备 5.提交 6.完成
3.准备 4.已准备 7.提交 8.完成
参与者
参与者
事务协调者
1.准备 2.已准备 5.回滚 6.完成
3.准备 4.已准备 7.回滚 8.完成
参与者状态机改造的几种方案
一、在业务状态中带入分布式事务状态。
适用情况，状态机比较简单，加入后不会对业务流程造成很大影 响。
二、业务流水表上新增一个分布式事务状态字段。
比如支付在充值完成后需要完成支付时，业务状态停在“已充 值”，如果支付第1阶段成功，状态变成“已充值”-“预处理成 功”，第2阶段提交成功后，业务状态和分布式事务状态一起变化。 在一条记录上，变更时天生带有事务性。
参与者
参与者
分布式事务基本模型
XTS
1.开启主事务 2.已准备 5.提交
4.已准备 3.加入分支事务 6.提交 7.完成
发起者
参与者
XTS
1.开启主事务 2.已准备 5.回滚
4.已准备 3.加入分支事务 6.回滚 7.完成
发起者
参与者
分布式事务基本模型
协调者
注册主事务 事务提交 事务回查 恢复数据查询
business_action（分支事务）
字段 id activity_id system_id business_type 说明 逻辑主键 主事务id 系统id，二阶段提交 时区分目标系统 参与者使用，区分业 务类型，xts本身不 关心 参与者使用，xts不 关心 创建时间 修改时间
Context gmt_create gmt_modified
未来对于主路径肯定是主推同库模式，异库模式 也需要支持。
根据业务实际情况，采用异库的模式。
xts：extended transaction service
大纲
基本原理 服务端设计 应用改造方案 典型业务场景 接入方式
分布式事务主要模型
business_activity（主事务）
字段 id activity_id system_id business_typ e state 说明 逻辑主键 随机生成的一段永不重 复的id 系统id，在回查的时候 用来区分目标系统 业务类型，给发起者使 用，xts本身不关心 状态，I（初始化），C （已提交），R（已回 滚），U（未知） 传播范围，暂不使用 发起者使用，xts不关心 创建时间 修改时间