分布式事务 全面解析

2024-09-08 01:08
文章标签 全面 解析 分布式 事务

本文主要是介绍分布式事务 全面解析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1 面试题

分布式事务了解吗?你们如何解决分布式事务问题的?

2 考点分析

只要聊到做了分布式系统,必问分布式事务,若你对分布式事务一无所知的话,确实很坑,起码得知道有哪些方案,一般怎么来做,每个方案的优缺点是什么。

现在面试,分布式系统成了标配,而分布式系统带来的分布式事务也成了标配.

你做系统肯定要用事务,那你用事务的话,分布式系统之后肯定要用分布式事务.

先不说你搞过没有,起码你得明白有哪几种方案,每种方案可能有啥坑?比如TCC方案的网络问题、XA方案的一致性问题

  • 单块系统里的事务

 

  • 分布式系统里的事务

 

3 XA方案也叫做两阶段提交事务方案.

举个例子,比如公司经常团建,然后一般会有个主席(就是负责组织团建的那个人)。

tb,team building,团建
  • 第一个阶段,一般tb主席会提前问团队里的每个人,说,大家伙,下周六我们去滑雪+烧烤,去吗? - 这个时候tb主席开始等待每个人的回答,如果所有人都说ok,那么就可以决定一起去这次tb - 如果这个阶段里,任何一个人回答说,我有事不去了,那么tb主席就会取消这次活动
  • 第二个阶段,那下周六大家就一起去滑雪+烧烤了

这就是所谓的XA事务,两阶段提交

有一个事务管理器,负责协调多个数据库(资源管理器)的事务,事务管理器先问各个数据库你准备好了吗?

  • 如果每个数据库都回复ok,那么就正式提交事务,在各个数据库上执行操作
  • 任何一个数据库回答不ok,那么就回滚事务。

这种分布式事务方案,比较适合单块应用中,跨多个库的分布式事务,而且因为严重依赖于数据库层面来搞定复杂的事务,效率很低,绝对不适合高并发场景

如果要玩,那么基于Spring + JTA就可以搞定,自己随便搜个demo看看~

这个方案,很少用,一般某个系统内部如果出现跨多个库的操作,是不合规的!

现在的微服务,一个大的系统分成几十甚至上百个服务。一般来说,我们的规约,是要求每个服务只能操作自己对应的一个数据库!

如果你要操作别的服务对应的库,不允许直连别的服务的库,违反微服务架构的规范

你随便交叉访问,几百个服务的话,全体乱套,这样的一套服务是没法管理的,会经常数据被别人改错,自己的库被别人写挂!

如果你要操作别人的服务的库,你必须通过调用别的服务的接口实现,绝对不允许你交叉访问别人的数据库!

  • 两阶段提交方案示意图

 

4 TCC方案

全称:Try、Confirm、Cancel

4.1 三个阶段

4.1.1 Try

对各个服务的资源做检测,对资源进行锁定或者预留

4.1.2 Confirm

在各个服务中执行实际的操作

4.1.3 Cancel

如果任何一个服务的业务方法执行出错,那么这里就需要进行补偿,即执行已操作成功的业务逻辑的回滚操作

4.2 跨银行转账案例

涉及到两个银行的分布式事务,如果用TCC方案来实现,思路是这样的:

  • Try阶段 先把两个银行账户中的资金给它冻结住,不让操作了
  • Confirm阶段 执行实际的转账操作,A银行账户的资金扣减,B银行账户的资金增加
  • Cancel阶段 如果任何一个银行的操作执行失败,那么就需要回滚进行补偿 比如A银行账户如果已经扣减了,但是B银行账户资金增加失败了,那么就得把A银行账户资金给加回去

该方案说实话几乎很少使用,但也有使用场景.

因为这个事务的回滚实际上严重依赖于你自己写代码来回滚和补偿了,会造成补偿代码巨大,非常恶心!

比如说我们,一般来说和钱相关的支付、交易等相关的场景,我们会用TCC,严格严格保证分布式事务要么全部成功,要么全部自动回滚,严格保证资金的正确性!

4.3 适用场景

除非你是真的一致性要求太高,是系统中核心之核心的场景!

常见的就是资金类的场景,那可以用TCC方案,自己编写大量的业务逻辑,自己判断一个事务中的各个环节是否ok,不ok就执行补偿/回滚代码

而且最好是你的各个业务执行的时间都比较短

但是说实话,一般尽量别这么搞,自己手写回滚逻辑,或者是补偿逻辑,实在太恶心了,业务代码也很难维护

  • TCC方案

 

5 本地消息表

ebay搞出来的这么一套思想

5.1 简介

  • A系统在本地一个事务里操作的同时,插入一条数据到消息表
  • 接着A系统将这个消息发送到MQ
  • B系统接收到消息后,在一个事务里,往自己本地消息表里插入一条数据,同时执行其他的业务操作,如果这个消息已经被处理过了,那么此时这个事务会回滚,这样保证不会重复处理消息
  • B系统执行成功后,就会更新自己本地消息表的状态以及A系统消息表的状态
  • 如果B系统处理失败,那么就不会更新消息表状态,那么此时A系统会定时扫描自己的消息表,如果有未处理的消息,会再次发送到MQ中去,让B再处理

5.2 优点

这个方案保证了最终一致性

哪怕B事务失败了,但是A会不断重发消息,直到B那边成功为止

5.3 缺陷

最大的问题就在于严重依赖于数据库的消息表来管理事务,这个会导致高并发场景无力,难以扩展呢,一般确实很少用

  • 本地消息表方案

 

6 可靠消息最终一致性方案

干脆不用本地的消息表了,直接基于MQ来实现事务。比如阿里的RocketMQ就支持消息事务!

6.1 简介

  • A系统先发送一个prepared消息到MQ,如果这个prepared消息发送失败,那么就直接取消操作,不执行了
  • 如果这个消息发送成功过了,那么接着执行本地事务,如果成功就告诉MQ发送确认消息,如果失败就告诉MQ回滚消息
  • 如果发送了确认消息,那么此时B系统会接收到确认消息,然后执行本地的事务
  • MQ会自动定时轮询所有prepared消息回调你的接口,问你这个消息是不是本地事务处理失败了,所有没发送确认的消息,是继续重试还是回滚? 这里你就可以查下数据库看之前本地事务是否执行,如果回滚了,那么这里也回滚吧。这个就是避免可能本地事务执行成功了,别确认消息发送失败了。
  • 如果系统B的事务失败了咋办? 重试咯,自动不断重试直到成功,如果实在是不行,要么就是针对重要的资金类业务进行回滚,比如B系统本地回滚后,想办法通知系统A也回滚;或者是发送报警由人工来手工回滚和补偿

这个还是比较合适的,目前国内互联网公司大都是这么玩的,要不你举用RocketMQ支持的,要不你就自己基于类似ActiveMQ?RabbitMQ?自己封装一套类似的逻辑出来,总之思路就是这样子的

  • 可靠消息最终一致性方案

 

 

7 最大努力通知方案

7.1 简介

  • 系统A本地事务执行完后,发送一个消息到MQ
  • 有一专门消费MQ的最大努力通知服务,会消费MQ,然后写入数据库中记录下来,亦可是放入内存队列,接着调用系统B的接口
  • 若系统B执行成功就ok;若系统B执行失败,那么最大努力通知服务就定时尝试重新调用系统B,反复N次,最后还是不行才放弃
  • 最大努力通知方案示意图

 

8 总结

你们公司是如何处理分布式事务的呢?欢迎评论交流!

讲真的,该突破面试教程没法带着大家实战,因为定位不是这个.

如果你真的被问到,你可以这么说,我们某某特别严格的场景,用的是TCC来保证强一致性;然后其他的一些场景基于了阿里的RocketMQ来实现了分布式事务~

你找一个严格资金要求绝对不能错的场景,你可以说你是用的TCC方案

如果是一般的分布式事务场景,订单插入之后要调用库存服务更新库存,库存数据没有资金那么的敏感,可以用可靠消息最终一致性方案

Rocketmq 3.2.6之前的版本,是可以按照上面的思路来的,但是之后接口做了一些改变,不再赘述,欢迎关注后续笔者的RocketMQ实战系列

当然如果你愿意,你可以参考可靠消息最终一致性方案来自己实现一套分布式事务,比如基于RabbitMQ来玩儿。

你其实用任何一个分布式事务的这么一个方案,都会导致你那块儿代码会复杂10倍。很多情况下,系统A调用系统B、系统C、系统D,我们可能根本就不做分布式事务。如果调用报错会打印异常日志。

每个月也就那么几个bug,很多bug是功能性的,体验性的,真的是涉及到数据层面的一些bug,一个月就几个,两三个?如果你为了确保系统自动保证数据100%不能错,上了几十个分布式事务,代码太复杂;性能太差,系统吞吐量、性能大幅度下跌。

99%的分布式接口调用,不要做分布式事务,直接就是监控(发邮件、发短信)、记录日志(一旦出错,完整的日志)、事后快速的定位、排查和出解决方案、修复数据。

每个月,每隔几个月,都会对少量的因为代码bug,导致出错的数据,进行人工的修复数据,自己临时动手写个程序,可能要补一些数据,可能要删除一些数据,可能要修改一些字段的值。

比你做50个分布式事务,成本要来的低上百倍,低几十倍

trade off,权衡,要用分布式事务的时候,一定是有成本,代码会很复杂,开发很长时间,性能和吞吐量下跌,系统更加复杂更加脆弱反而更加容易出bug;好处,如果做好了,TCC、可靠消息最终一致性方案,一定可以100%保证你那快数据不会出错。

1%,0.1%,0.01%的业务,资金、交易、订单,我们会用分布式事务方案来保证,会员积分、优惠券、商品信息,其实不要这么搞了

这篇关于分布式事务 全面解析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1146681

相关文章

网页解析 lxml 库--实战

lxml库使用流程 lxml 是 Python 的第三方解析库,完全使用 Python 语言编写,它对 XPath表达式提供了良好的支 持,因此能够了高效地解析 HTML/XML 文档。本节讲解如何通过 lxml 库解析 HTML 文档。 pip install lxml lxm| 库提供了一个 etree 模块,该模块专门用来解析 HTML/XML 文档,下面来介绍一下 lxml 库

【C++】_list常用方法解析及模拟实现

相信自己的力量,只要对自己始终保持信心,尽自己最大努力去完成任何事,就算事情最终结果是失败了,努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一:什么是list? •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二:list常用接口 •🌰1.默认成员函数 🔥构造函数(⭐) 🔥析构函数 •🌰2.list对象

OWASP十大安全漏洞解析

OWASP(开放式Web应用程序安全项目)发布的“十大安全漏洞”列表是Web应用程序安全领域的权威指南,它总结了Web应用程序中最常见、最危险的安全隐患。以下是对OWASP十大安全漏洞的详细解析: 1. 注入漏洞(Injection) 描述:攻击者通过在应用程序的输入数据中插入恶意代码,从而控制应用程序的行为。常见的注入类型包括SQL注入、OS命令注入、LDAP注入等。 影响:可能导致数据泄

从状态管理到性能优化:全面解析 Android Compose

文章目录 引言一、Android Compose基本概念1.1 什么是Android Compose?1.2 Compose的优势1.3 如何在项目中使用Compose 二、Compose中的状态管理2.1 状态管理的重要性2.2 Compose中的状态和数据流2.3 使用State和MutableState处理状态2.4 通过ViewModel进行状态管理 三、Compose中的列表和滚动

Spring 源码解读:自定义实现Bean定义的注册与解析

引言 在Spring框架中,Bean的注册与解析是整个依赖注入流程的核心步骤。通过Bean定义,Spring容器知道如何创建、配置和管理每个Bean实例。本篇文章将通过实现一个简化版的Bean定义注册与解析机制,帮助你理解Spring框架背后的设计逻辑。我们还将对比Spring中的BeanDefinition和BeanDefinitionRegistry,以全面掌握Bean注册和解析的核心原理。

CSP 2023 提高级第一轮 CSP-S 2023初试题 完善程序第二题解析 未完

一、题目阅读 (最大值之和)给定整数序列 a0,⋯,an−1,求该序列所有非空连续子序列的最大值之和。上述参数满足 1≤n≤105 和 1≤ai≤108。 一个序列的非空连续子序列可以用两个下标 ll 和 rr(其中0≤l≤r<n0≤l≤r<n)表示,对应的序列为 al,al+1,⋯,ar​。两个非空连续子序列不同,当且仅当下标不同。 例如,当原序列为 [1,2,1,2] 时,要计算子序列 [

多线程解析报表

假如有这样一个需求,当我们需要解析一个Excel里多个sheet的数据时,可以考虑使用多线程,每个线程解析一个sheet里的数据,等到所有的sheet都解析完之后,程序需要提示解析完成。 Way1 join import java.time.LocalTime;public class Main {public static void main(String[] args) thro

ZooKeeper 中的 Curator 框架解析

Apache ZooKeeper 是一个为分布式应用提供一致性服务的软件。它提供了诸如配置管理、分布式同步、组服务等功能。在使用 ZooKeeper 时,Curator 是一个非常流行的客户端库,它简化了 ZooKeeper 的使用,提供了高级的抽象和丰富的工具。本文将详细介绍 Curator 框架,包括它的设计哲学、核心组件以及如何使用 Curator 来简化 ZooKeeper 的操作。 1

集中式版本控制与分布式版本控制——Git 学习笔记01

什么是版本控制 如果你用 Microsoft Word 写过东西,那你八成会有这样的经历: 想删除一段文字,又怕将来这段文字有用,怎么办呢?有一个办法,先把当前文件“另存为”一个文件,然后继续改,改到某个程度,再“另存为”一个文件。就这样改着、存着……最后你的 Word 文档变成了这样: 过了几天,你想找回被删除的文字,但是已经记不清保存在哪个文件了,只能挨个去找。真麻烦,眼睛都花了。看

MySql 事务练习

事务(transaction) -- 事务 transaction-- 事务是一组操作的集合,是一个不可分割的工作单位,事务会将所有的操作作为一个整体一起向系统提交或撤销请求-- 事务的操作要么同时成功,要么同时失败-- MySql的事务默认是自动提交的,当执行一个DML语句,MySql会立即自动隐式提交事务-- 常见案例:银行转账-- 逻辑:A给B转账1000:1.查询