《凤凰架构》 -分布式事务章节 读书笔记

2024-02-24 15:52

本文主要是介绍《凤凰架构》 -分布式事务章节 读书笔记,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

分布式事务严谨的定义:分布式环境下的事务处理机制

CAP定理:在一个分布式系统中,涉及共享数据问题时,以下三个特性最多只能同时满足两个

        一致性:代表数据在任何时刻、任何分布式节点中看到的都是符合预期的,一致性概念在分布式研究中是有严肃定义和多种细分类型的概念(与分布式共识算法中的面向副本复制的一致性不同,此处指的是面向数据库状态的一致性)。

        可用性:代表系统不间断的提供服务的能力,与其密切相关的两个指标为可用性和可维护性。可靠性使用平均无故障时间来度量,可维护性用平均可修复时间来度量

        分区容忍性:代表分布式环境中部分节点因为网络原因而彼此失联后,即与其他节点形成“网络分区时”,系统仍能正确地提供服务的能力。

选择放弃一致性的AP系统是目前设计分布式系统的主流选择,因为:

        1、P是分布式网络的天然属性(永远可靠的通信在分布式系统中必定不成立,这不是设计者想不想的问题,而是只要用到网络来共享数据,分区现象就会始终存在),目前条件下,无论如何设计也无法避免P的出现

        2、A是建设分布式系统的目的,如果可用性随着节点数量增加反而降低的话,很多分布式系统就失去了价值。除非是银行、证券这些涉及金钱交易的服务,宁可中断也不能出错,否则多数系统是不能容忍节点越多可用性反而越低的。

需要注意的是CAP和ACID理论中的一致性称为强一致性或者在线一致性。无论如何,我们建设信息系统终究还是要确保操作结果至少在最终交付的时候是正确的(解读:允许数据在中间过程中出错(不一致), 但应该在输出时被修正过来)。因此在牺牲了C的AP系统中,要尽可能地获得正确的结果的行为称为追求“弱一致性”。在强一致性和弱一致性之间还存在着最终一致性:如果数据在一段时间内没有被另外的操作所更改,那么它最终会达到与强一致性过程相同的结果。面向最终一致性的算法也被称为“乐观复制算法”。

TCC分布式事务机制:TCC由“try-confirm-cancel”三个单词缩写而成。如同TCC名字所示,它分为如下三个过程:

        1、Try:尝试执行阶段,完成所有业务可执行性的检查(保障一致性),并且预留好全部需要用到的业务资源(保障隔离性);

        2、Confirm阶段:确认执行阶段,不进行任何业务检查,直接使用Try阶段准备的资源来完成业务处理。Confirm阶段可能会重复执行(失败重试导致的),因此本阶段所执行的操作需要具备幂等性(即多次执行结果和执行一次的结果相同)

        3、Cancel阶段:取消执行阶段,释放Try阶段预留的业务资源。Cancel阶段也可能会重复执行,因此也需要满足幂等性

TCC其实有点类似于2PC的准备阶段和提交阶段,但是TCC位于用户代码层面(即业务代码,写业务代码的程序员相对于基础库而言都是用户),而不是基础设施层面。

TCC业务侵入性和开发成本都很高,所以一般我们不会完全靠裸编码实现TCC,而是会借助一些分布式事务中间件去完成,尽可能地减轻编码工作量。

SAGA事务:TCC事务是常见柔性事务中性能最高的,但是它并不能满足所有场景,因此有了SAGA事务。SAGA事务的设计思路:把一个大事务分解,目的是为了避免大事务长时间锁定数据库的资源。 SAGA由两部分操作组成:

        1、大事务拆分成若干个小事务,整个分布式事务T分解成n个子事务,命名为T_1T_2,…,T_i,…,T_n。每个子事务都应该是或者能被视为是原子行为。如果分布式事务能够正常提交,其对数据的影响(最终一致性)应与连续按顺序成功提交 T_i等价。

        2、为每个子事务设计一个对应的补偿动作,命名为C_1,C_2,...C_i,...C_nT_iC_i需要满足如下条件:(1)T_iC_i都具备幂等性;(2)T_iC_i满足交换律,即无论是先执行T_i还是C_i,其效果都是一样的;(3)C_i必须能成功提交,即不考虑C_i本身提交失败回滚的情形,如出现C_i本身提交失败,就必须持续重试直至成功或者人工介入。

如果T_1T_n均成功提交,那么事务顺利完成,否则就需要采用正向恢复策略或者反向恢复策略。

正向恢复(Forward Recovery): 如果事务T_i提交失败,则一直对T_i进行重试直到成功为止(最大努力交付),这种恢复方式不需要补偿,适用于事务最终都要成功的场景,正向恢复的执行模式为:T_1,T_2,...,T_i(失败),T_i(重试),...,T_{i+1},...T_n

反向恢复(Backward Recovery):如果事务T_i提交失败,则一直执行C_iT_i进行补偿,直到成功为止(最大努力交付)。这里要求C_i(可通过持续重试)必须执行成功。反向恢复的执行模式为:T_1,T_2,...T_i(失败),C_i(补偿),...,C_2,C_1

SAGA必须保证所有子事务都得以提交或者补偿,但实际SAGA系统本身也有可能会崩溃,所以他必须被设计成数据库类似的日志机制以保证系统恢复后可以追踪到子事务的执行情况。例如直行道哪一步或者补偿到哪一步了。

这篇关于《凤凰架构》 -分布式事务章节 读书笔记的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



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

相关文章

MySQL 缓存机制与架构解析(最新推荐)

《MySQL缓存机制与架构解析(最新推荐)》本文详细介绍了MySQL的缓存机制和整体架构,包括一级缓存(InnoDBBufferPool)和二级缓存(QueryCache),文章还探讨了SQL... 目录一、mysql缓存机制概述二、MySQL整体架构三、SQL查询执行全流程四、MySQL 8.0为何移除查

MYSQL事务死锁问题排查及解决方案

《MYSQL事务死锁问题排查及解决方案》:本文主要介绍Java服务报错日志的情况,并通过一系列排查和优化措施,最终发现并解决了服务假死的问题,文中通过代码介绍的非常详细,需要的朋友可以参考下... 目录问题现象推测 1 - 客户端无错误重试配置推测 2 - 客户端超时时间过短推测 3 - mysql 版本问

微服务架构之使用RabbitMQ进行异步处理方式

《微服务架构之使用RabbitMQ进行异步处理方式》本文介绍了RabbitMQ的基本概念、异步调用处理逻辑、RabbitMQ的基本使用方法以及在SpringBoot项目中使用RabbitMQ解决高并发... 目录一.什么是RabbitMQ?二.异步调用处理逻辑:三.RabbitMQ的基本使用1.安装2.架构

java如何分布式锁实现和选型

《java如何分布式锁实现和选型》文章介绍了分布式锁的重要性以及在分布式系统中常见的问题和需求,它详细阐述了如何使用分布式锁来确保数据的一致性和系统的高可用性,文章还提供了基于数据库、Redis和Zo... 目录引言:分布式锁的重要性与分布式系统中的常见问题和需求分布式锁的重要性分布式系统中常见的问题和需求

Redis事务与数据持久化方式

《Redis事务与数据持久化方式》该文档主要介绍了Redis事务和持久化机制,事务通过将多个命令打包执行,而持久化则通过快照(RDB)和追加式文件(AOF)两种方式将内存数据保存到磁盘,以防止数据丢失... 目录一、Redis 事务1.1 事务本质1.2 数据库事务与redis事务1.2.1 数据库事务1.

Golang使用etcd构建分布式锁的示例分享

《Golang使用etcd构建分布式锁的示例分享》在本教程中,我们将学习如何使用Go和etcd构建分布式锁系统,分布式锁系统对于管理对分布式系统中共享资源的并发访问至关重要,它有助于维护一致性,防止竞... 目录引言环境准备新建Go项目实现加锁和解锁功能测试分布式锁重构实现失败重试总结引言我们将使用Go作

Redis分布式锁使用及说明

《Redis分布式锁使用及说明》本文总结了Redis和Zookeeper在高可用性和高一致性场景下的应用,并详细介绍了Redis的分布式锁实现方式,包括使用Lua脚本和续期机制,最后,提到了RedLo... 目录Redis分布式锁加锁方式怎么会解错锁?举个小案例吧解锁方式续期总结Redis分布式锁如果追求

SpringBoot嵌套事务详解及失效解决方案

《SpringBoot嵌套事务详解及失效解决方案》在复杂的业务场景中,嵌套事务可以帮助我们更加精细地控制数据的一致性,然而,在SpringBoot中,如果嵌套事务的配置不当,可能会导致事务不生效的问题... 目录什么是嵌套事务?嵌套事务失效的原因核心问题:嵌套事务的解决方案方案一:将嵌套事务方法提取到独立类

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。