老爷爷都能看懂的微服务架构系列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☀️分布式事务介绍-全面详细的主要内容,如果未能解决你的问题,请参考以下文章

小白都能看懂的分布式事务与2PC

用大白话告诉你小白都能看懂的Hadoop架构原理

小白都能看懂的 Dubbo 入门

分布式系统关注点——99%的人都能看懂的「熔断」以及最佳实践

小白都能看懂的Linux系统下安装配置Zabbix

小白都能看懂的Linux系统下安装配置Zabbix