分布式事务几种实现方式

• 1.分布式事务产生的背景
• 2.X/OpenDTP事务模型
• 3.Mysql事务处理过程
• 4. 2PC协议
• 5.3PC协议
• 6.分布式事务的实现
• 7.MQ实现最终一致性
• 8.LCN实现

1.分布式事务产生的背景

根据业务需求需要对业务进行拆分,例如将一个大应用拆分成用户模块,订单模块,商品模块,每个模块都有自己的数据库,在用户购买商品的时候需要扣减商品模块库存,在订单模块添加订单数据,这时候需要保证这两个数据库操作在同一个事务中完成,因此就出现了分布式事务

2.X/OpenDTP事务模型

概念: X/Open是一个组织机构,定义了一套分布式事务标准,定义了规范的API接口
角色:
- AP application
- RM resouces manager 资源管理器
- TM transaction manager事务管理器

3.Mysql事务处理过程

3.1 记录redo日志和undo日志,确保日志在磁盘上的持久化
3.2 更新数据记录
3.3 提交事务,redo写入commit记录

4. 2PC协议

两阶段提交
- 阶段一:提交事务请求
1. TM向所有的AP发送事务内容，询问是否可以执行事务的提交操作，并等待各个AP的响应
2. 执行事务
各个AP节点执行事务操作，将undo和redo信息记录到事务日志中，尽量把提交过程中所消耗时间的操作和准备都提前完成后确保后续
事务提交的成功率
3. 各个AP向TM反馈事务询问的响应
各个AP成功执行了事务操作，那么反馈给TM yes的response；如果AP没有成功执行事务，就反馈TM no的response
- 阶段二: 执行事务提交

- 存在的问题
1. 数据一致性问题:当AP和TM都宕机了,新选出来的TM不知道宕机的AP到底做了什么操作,如果根据剩下的两个存活的AP的操作(commit或者abort)作为判断,则很可能会因为宕机的操作和存活的操作不一致导致数据不一致
2. 同步阻塞:第二阶段中,如果所有的AP都宕机了.则TM只能阻塞等待AP的返回

5.3PC协议

• 阶段一：canCommit:TM请求AP是否可以commit
• 阶段二：preCommit
• 阶段三：doCommit

6.分布式事务的实现

- atomikos

7.MQ实现最终一致性

7.1消息重复消费解决方案

• 幂等校验:在消费端新建一张表,使用唯一索引,消费数据前往数据表插入一条数据,如果插入成功则证明是第一次消费,如果插入失败则证明已经不是第一次消费
• 日志表来判断,或者通过状态锁来判断,消费端创建一个日志表,消费时插入一个id和状态,消费成功后去更新状态
  最终一致性模式:
• 查询模式
• 补偿模式:A调用B,失败后自动重试,回滚原有操作,若不能自动重试则通知运营,人工补偿(如人工对账),或通知技术,监控,预警
• TCC事务模型
  

8.LCN实现

• 服务消费方加注解 @TxcTransaction(timeout = 1000 * 10)
• 服务提供方获取全局事务ID,并绑定到上下文

public int updateStock(OrderDO orderDO) {

//获取全局事务ID，并绑定到上下文

String xid = RpcContext.getContext().getAttachment("xid");

TxcContext.bind(xid,null);

//执行自己的业务逻辑

int ret = jdbcTemplate.update("update stock set amount = amount - ? where product_id = ?",new Object[]{orderDO.getNumber(), orderDO.getProductId()});

TxcContext.unbind();

return ret;

}