分布式事务几种实现方式

分布式事务几种实现方式

环游记 2018-08-05 22:51:00  38728  收藏 33
分类专栏： ❀项目实战
版权
强烈推荐一个大神的人工智能的教程：http://www.captainbed.net/zhanghan

文章目录
1.分布式事务产生的背景
[2.X/OpenDTP事务模型](https://mp.weixin.qq.com/s/RDnf637MY0IVgv2NpNVByw)
3.Mysql事务处理过程
4. 2PC协议
5.3PC协议
6.分布式事务的实现
7.MQ实现最终一致性
7.1消息重复消费解决方案
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协议
两阶段提交

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

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

}

————————————————
版权声明：本文为CSDN博主「环游记」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zh15732621679/article/details/81436751