分布式事务几种实现方式

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/zh15732621679/article/details/81436751

强烈推荐一个大神的人工智能的教程:http://www.captainbed.net/zhanghan

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事务模型
    image

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;

}

展开阅读全文

没有更多推荐了,返回首页