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




文章目录

* 1.分布式事务产生的背景
<https://blog.csdn.net/zh15732621679/article/details/81436751#1_4>
* [2.X/OpenDTP事务模型](https://mp.weixin.qq.com/s/RDnf637MY0IVgv2NpNVByw)
<https://blog.csdn.net/zh15732621679/article/details/81436751#2XOpenDTPhttpsmpweixinqqcomsRDnf637MY0IVgv2NpNVByw_6>
* 3.Mysql事务处理过程
<https://blog.csdn.net/zh15732621679/article/details/81436751#3Mysql_12>
* 4. 2PC协议
<https://blog.csdn.net/zh15732621679/article/details/81436751#4_2PC_16>
* 5.3PC协议
<https://blog.csdn.net/zh15732621679/article/details/81436751#53PC_30>
* 6.分布式事务的实现
<https://blog.csdn.net/zh15732621679/article/details/81436751#6_35>
* 7.MQ实现最终一致性
<https://blog.csdn.net/zh15732621679/article/details/81436751#7MQ_38>
* 7.1消息重复消费解决方案
<https://blog.csdn.net/zh15732621679/article/details/81436751#71_39>
* 8.LCN实现
<https://blog.csdn.net/zh15732621679/article/details/81436751#8LCN_47>


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


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

<>2.X/OpenDTP事务模型 <https://mp.weixin.qq.com/s/RDnf637MY0IVgv2NpNVByw>

概念: 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; }

友情链接
KaDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:[email protected]
QQ群:637538335
关注微信