架构系列——分布式事务

简介: 架构系列——分布式事务

前言

系统一旦分布式了之后,通信、缓存、消息、事务、锁、配置、日志、监控、会话等等各种原来单块系统场景下很容易解决的问题,都会变得很复杂,需要引入大量外部的技术。

本文对分布式基础知识点做出一定的总结,适合想要了解分布式或者刚开始接触分布式的程序员阅读。


一、分布式框架

如果要让不同的子系统或者服务之间互相通信,首先必须有一套分布式服务框架。也就是各个服务可以互相感知到对方在哪里,可以发送请求过去,可以通过HTTP或者RPC的方式。

最常见的技术就是dubbo以及spring cloud,当然大厂一般都是自己有服务框架。


二、分布式事务

2.1 事务特性

ACID

A原子性:在事务的执行过程中,要么全部执行成功,要么都不成功。


C一致性:事务在执行前后,不能破坏数据的完整性。一致性更多的说的是通过AID来达到目的,数据应该符合预先的定义和约束,由应用层面来保证,还有的说法是C是强行为了ACID凑出来的。


I隔离性:多个事务之间是互相隔离的,事务之间不能互相干扰,涉及到不同事务的隔离级别的问题。


D持久性:一旦事务提交,数据库中数据的状态就应该是永久性的。


一个数据库的本地事务机制仅仅对落到自己身上的操作起作用,无法干涉对其他数据库的查询操作。所以,数据库自身提供的本地事务机制无法确保业务对多数据源全局操作的可靠性。


基于此,针对多数据源操作提出的分布式事务机制就出现了。


2.2 分布式事务模型

- 事务参与者:例如每个数据库就是一个事务参与者


- 事务协调者:访问多个数据源的服务程序,例如 shopping-service 就是事务协调者


- 资源管理器(Resource Manager, RM):通常与事务参与者同义


- 事务管理器(Transaction Manager, TM):通常与事务协调者同义


2.3 二将军问题和幂等性

一支白军被围困在一个山谷中,山谷的左右两侧是蓝军。困在山谷中的白军人数多于山谷两侧的任意一支蓝军,而少于两支蓝军的之和。若一支蓝军对白军单独发起进攻,则必败无疑;但若两支蓝军同时发起进攻,则可取胜。两只蓝军的总指挥位于山谷左侧,他希望两支蓝军同时发起进攻,这样就要把命令传到山谷右侧的蓝军,以告知发起进攻的具体时间。假设他们只能派遣士兵穿越白军所在的山谷(唯一的通信信道)来传递消息,那么在穿越山谷时,士兵有可能被俘虏。


网络二将军问题的存在使得消息的发送者往往要重复发送消息,直到收到接收者的确认才认为发送成功,但这往往又会导致消息的重复发送。例如电商系统中订单模块调用支付模块扣款的时候,如果网络故障导致二将军问题出现,扣款请求重复发送,产生的重复扣款结果显然是不能被接受的。因此要保证一次事务中的扣款请求无论被发送多少次,接收方有且只执行一次扣款动作,这种保证机制叫做接收方的幂等性。


2.4 CAP 定理

一个系统不可能同时满足一致性(C:Consistency),可用性(A: Availability)和分区容错性(P:Partition tolerance),最多只能同时满足其中的2个。分布式系统必须满足分区容错性,剩下一个是从一致性和可用性之间做权衡,但是最终都要达到一致性。


Eureca:满足AP

Zookeeper:满足CP

2.5 Base 理论

全称:Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)


即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。


2.6 XA

分布式事务处理的规范,是一个规范或者说是协议,定义了事务管理器TM(Transaction Manager),资源管理器RM(Resource Manager)和应用程序。

XA定义了规范,那么2PC和3PC就是它的具体实现方式。

2.7 二阶段提交 2PC

Two-Phase Commit,事务的提交过程分成了两个阶段来进行处理。

投票阶段

TM向所有的参与者发送prepare请求,询问是否可以执行事务,等待各个参与者的响应。


这个阶段可以认为只是执行了事务的SQL语句,但是还没有提交。


如果都执行成功了就返回YES,否则返回NO。


执行阶段


执行阶段就是真正的事务提交的阶段,但是要考虑到失败的情况。


如果所有的参与者都返回YES,那么就执行发送commit命令,参与者收到之后执行提交事务。


反之,只要有任意一个参与者返回的是NO的话,就发送rollback命令,然后执行回滚的操作。


2PC的缺陷


1.同步阻塞,可以看到,在执行事务的过程当中,所有数据库的资源都被锁定,如果这时候有其他人来访问这些资源,将会被阻塞,这是一个很大的性能问题。


2.TM单点故障问题,只要一个TM,一旦TM宕机,那么整个流程无法继续完成。


3.数据不一致,如果在执行阶段,参与者脑裂或者其他故障导致没有收到commit请求,部分提交事务,部分未提交,那么数据不一致的问题就产生了。


2.8 三阶段提交 3PC

既然2PC有这么多问题,所以就衍生出了3PC的概念,也叫做三阶段提交,他把整个流程分成了CanCommit、PreCommit、DoCommit三个步骤,相比2PC,增加的就是CanCommit阶段。


与两阶段提交不同的是,三阶段提交有两个改动点。


1.引入超时机制。同时在协调者和参与者中都引入超时机制。


2.在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。


也就是说,除了引入超时机制之外,3PC把2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。


相比2PC的改进


对于2PC的同步阻塞的问题,我们可以看到因为3PC加入了参与者的超时机制,所以原来2PC的如果某个参与者故障导致的同步阻塞的问题时间缩短了,这是一个优化,但是并没有完全避免。


第二个单点故障的问题,同样因为超时机制的引入,一定程度上也算是优化了。


但是数据不一致的问题,这个始终没有得到解决。


2.9 TCC

TCC的模式叫做Try、Confirm、Cancel,实际上也就是2PC的一个变种而已。


实现这个模式,一个事务的接口需要拆分成3个,也就是Try预占、Confirm确认提交、最后Cancel回滚。


几个比较不错的框架,都是国内开源的:ByteTCC,tcc-transaction,himly


2.10 消息队列

以上都是一些理论,生产环境中很少有人用到。而基于消息队列来实现最终一致性的方案,这个相比前面的我个人认为还稍微靠谱一点。基于消息队列的可能真正在应用的还稍微多一点。


这个方案基于MQ来保证消息事务的最终一致性,还算是一个比较合理的解决方案,只要保证MQ的可靠性就可以正常实施应用,业务消费方根据本身的消息重试达到最终一致性。


参考文献:

[1].Java同学找工作最懵圈的问题:到底啥是分布式系统开发经验?

[2].《我想进大厂》之分布式事务篇

[3].搞定分布式,程序员进阶之路

[4].瞅一眼?25张图让你彻底掌握分布式事务原理。

[5].分布式相关面试题

相关文章
|
2月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
2月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
2月前
|
存储 JSON 数据库
Elasticsearch 分布式架构解析
【9月更文第2天】Elasticsearch 是一个分布式的搜索和分析引擎,以其高可扩展性和实时性著称。它基于 Lucene 开发,但提供了更高级别的抽象,使得开发者能够轻松地构建复杂的搜索应用。本文将深入探讨 Elasticsearch 的分布式存储和检索机制,解释其背后的原理及其优势。
181 5
|
21天前
|
消息中间件 关系型数据库 Java
‘分布式事务‘ 圣经:从入门到精通,架构师尼恩最新、最全详解 (50+图文4万字全面总结 )
本文 是 基于尼恩之前写的一篇 分布式事务的文章 升级而来 , 尼恩之前写的 分布式事务的文章, 在全网阅读量 100万次以上 , 被很多培训机构 作为 顶级教程。 此文修改了 老版本的 一个大bug , 大家不要再看老版本啦。
|
25天前
|
存储 安全 API
单元化架构,分布式系统的新王!
【10月更文挑战第9天】
92 0
单元化架构,分布式系统的新王!
|
1月前
|
存储 SQL 消息中间件
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
44 0
|
3月前
|
存储 NoSQL Java
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
这篇文章是关于Java面试中的分布式架构问题的笔记,包括分布式架构下的Session共享方案、RPC和RMI的理解、分布式ID生成方案、分布式锁解决方案以及分布式事务解决方案。
一天五道Java面试题----第十一天(分布式架构下,Session共享有什么方案--------->分布式事务解决方案)
|
3月前
|
机器学习/深度学习 分布式计算 Cloud Native
云原生架构下的高性能计算解决方案:利用分布式计算资源加速机器学习训练
【8月更文第19天】随着大数据和人工智能技术的发展,机器学习模型的训练数据量和复杂度都在迅速增长。传统的单机训练方式已经无法满足日益增长的计算需求。云原生架构为高性能计算提供了新的可能性,通过利用分布式计算资源,可以在短时间内完成大规模数据集的训练任务。本文将探讨如何在云原生环境下搭建高性能计算平台,并展示如何使用 PyTorch 和 TensorFlow 这样的流行框架进行分布式训练。
122 2
|
3月前
|
监控 Java 开发者
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流
随着软件开发的发展,传统单体应用已难以适应现代业务需求,微服务架构因此兴起,成为构建可伸缩、分布式系统的主流。本文探讨Java微服务架构的设计原则与实践。核心思想是将应用拆分为独立服务单元,增强模块化与扩展性。Java开发者可利用Spring Boot等框架简化开发流程。设计时需遵循单一职责、自治性和面向接口编程的原则。以电商系统为例,将订单处理、商品管理和用户认证等拆分为独立服务,提高可维护性和容错能力。还需考虑服务间通信、数据一致性及监控等高级话题。掌握这些原则和工具,开发者能构建高效、可维护的微服务应用,更好地应对未来挑战。
86 1
|
3月前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
123 6