老爷爷都能看懂的微服务架构系列001☀️分布式事务介绍-全面详细
Posted 毛毛是一只狗
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了老爷爷都能看懂的微服务架构系列001☀️分布式事务介绍-全面详细相关的知识,希望对你有一定的参考价值。
一:项目介绍
B2C, 微服务架构的项目
数据库表
二:在微服务架构中要面对的难点
1:扣减库存时候的超卖问题
2: 以及归还库存时候的数据错误问题
3: 订单超时问题
4: 下单时候的事务
产生以上问题的业务的流程图
三:分布式锁——解决的问题
1: 超卖问题,就是扣减库存避免数据错误
2:库存归还时的问题,原因同上
主要用到的解决方法:setnx,保证查找和修改的原子性
四:分布式事务
分布式事务这里要解决的问题
下单问题
下单和库存一直性问题
下订单和扣库存之间一致性的事务问题。
用户下单不支付问题
业务层面,永不下单不支付,但是库存减了,要买的人买不到,
当然也可以用户支付后在减库存,但是会出现一个问题,就是支付的时候已经没有库存了,但是已经下单了,用户体验非常非常不好。
所以就必须加入超时机制,用户下单后,一定时间不支付,归还库存。
什么是事务?
事务就是一组sql,可能涉及到很多表,这组sql,要么全部执行成功要么全部回滚取消执行,不允许一部分执行成功,这种特性就是“事务”!
什么是分布式事务?
分布式事务是由多个本地事务组合而成的,分布式事务就是在微服务中,一些服务相互调用时涉及到了很多表的sql语句,也要保证事务的特性。
什么是事务特性?
事务的特性:原子性,一致性,隔离性,持久性 ,简称ACID。
这里的原子性和一致性概念比较容易弄混,原子性指业务层面,所有功能全部成功,要么全部取消不执行,如下订单时和扣减库存的时候这两个功能要不争原子性。还有在分布式锁的时候setnx也是保证了原子性
而一致性是指数据的一致性,我给哥哥转钱,他收到,和我这边扣款保证一直,不能我扣款了,他没收到。
导致数据不一致的原因
1: 网络问题
硬件故障,网络抖动, 网络拥塞: 请求和返回是拥塞,但是以为失败了,做了回滚。
超时机制,重试
2:程序出错
宕机,端点,磁盘满了,电脑坏了等等
在以上问题基础上,保证事务的完整性。
关于分布式事务的两个重要理论
☀️视频讲解-cap和base理论☀️
cap理论
consistency,Availability ,Partition Tolerance
矛盾
consistency,Availability ,只能满足一个
为了达到数据一致性,读写数据库,在写的时候是不能读的,所以导致了不可用(读和写是两个不同的数据库)。
一致性和可用性看自己的需求选择
base理论(现在普遍用到的分布式理论基础)
基本可用
软状态
数据最终一致性
保证分布式事务解决方案
分布式中要保证的底线原则
同时成功同时失败
● 两阶段提交(2PC, Two-phase Commit)
优点:简单
缺点:开启事务和最后提交事务的时候,会锁表,并发会非常非常低。
● TCC 补偿模式(最复杂的方案)
☀️视频讲解-TCC分布式解决方案☀️
tcc管理器或者tcc日志完成事务的一致性(取代2pc中的事务锁表)
核心原理
try (冻结库存,数据库有冻结的字段)
commit (真正扣减库存)
cancel (把冻结的减掉就行了)
这是一个服务提供的三个函数接口
● 基于本地消息表实现最终一致性
☀️视频讲解-基于本地消息表实现最终一致性分布式事务方案☀️
基于本地消息表作用。
主要记录本地服务发送mq的情况,失败了就会记录一下,
以轮训的方式定期扫描这张本地消息表。
还有一个比较重要的问题,就是消息重复发送的问题,也需要解决这个问题,就需要再加一个流水表,每次查看的时候,看看有没有重复扣减。
● 最大努力通知
● 基于可靠消息最终一致性方案 (推荐)
基于rocketMQ提供的事务消息,和回查机制完成
以上是关于老爷爷都能看懂的微服务架构系列001☀️分布式事务介绍-全面详细的主要内容,如果未能解决你的问题,请参考以下文章