一:项目介绍
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提供的事务消息，和回查机制完成
扫一扫
2704
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
