[分布式事务-TCC] 1. 分布式事务的由来和TCC的核心思想和工作流程

分布式事务的由来和TCC的核心思想和工作流程

写在前面

分布式事务是一个大的命题,有很多相关的技术和细节。网上介绍这个主题的文章也是多如牛毛,但是能把问题的来龙去脉给讲清楚的文章并不多。

我也不敢说自己就一定能够把这个本来就很复杂的事情讲的有多通透。不过技术教学相长,知识常看常新。做一些努力将这个问题系统性地梳理二三也算是对自己日常的学习和工作做一点沉淀吧。

本系列文章计划是写系列文章来介绍TCC这一分布式事务在应用层的实现方案,包含下面几个主题:

  1. 分布式事务的由来和TCC的核心思想和工作流程
  2. TCC的异常处理方案
  3. TCC的各种优化方案

引子

系统初期一般都是单体应用架构(也即所谓的Monolith型应用),此时系统的所有业务服务都由少数几个系统对外提供。随着业务发展,单体应用会逐渐臃肿成为大杂烩,且系统内部耦合严重,牵一发而动全身。此时一般会针对应用提供的功能进行垂直拆分,实现应用的轻量化和微服务化。

由于原来的应用被拆分为数个微服务,原来的系统内部调用现在就不可避免的成为了分布式环境下的网络调用。因此一个简单的服务调用也会面临分布式环境下的一系列挑战:

  1. 网络可靠性问题
  2. 数据一致性问题
  3. 高可用以及灾备问题

针对每个问题都有各自的解决方案,本文主要聚焦于数据一致性问题。

分布式事务是解决分布式环境下的数据一致性问题的一种规范。而本文要讨论的TCC则是分布式事务的一种实现方案。

TCC是什么

TCC指的是一种资源,它是实现了Try-Confirm-Cancel这三个操作的接口。如果以经典的转账服务作为例子的话,就像下面这样:

在这里插入图片描述
比如我们需要将银行A下的某个账户中的钱转账到银行B下的某个账户,就需要依赖银行A的借记TCC资源和银行B的贷记TCC资源。

TCC体现的是一种资源预留的思想,就如同T - Try所展现的那样。首先会尝试预留业务活动需要的资源,如果所有业务参与方都成功地预留了所需资源,那么就意味着这笔业务能够顺利地进行下去,即C - Confirm的含义;反过来,如果有任何一个业务参与者无法预留所需的资源,那么意味着这笔业务无法推进,需要告知所有参与方释放预留的资源,即C - Cancel的含义。

TCC的核心思想

TCC是在应用层定义了类似2PC的标准两阶段接口,业务系统只需要实现对应的接口就可以使用分布式事务功能。

相对传统的XA模式,TCC去除了资源管理器(RM,通常指的是数据库系统)对于分布式事务的依赖。这是一个很大的优势,在如今分布式系统下大规模的部署能够支持分布式事务的资源管理器本身就是不现实的。

业务系统如果想要作为参与者加入到一笔分布式事务中来,只需要提供符合TCC规范的三种原子服务,并保证这些服务的幂等性。

另外,由于分布式事务未达到终态前会存在短暂的数据不一致现象,业务系统也需要能够兼容数据最终一致前带来的可见性问题。

关于短暂的数据不一致,可以举个简单的例子来帮助理解:对于从A账户转账到B账户的场景。

当A已经扣款而B还未收款的中间状态,用户需要知道的是这笔钱正处于转账的途中(预留状态),而不是看到这笔钱莫名其妙地消失了然而B账户还未收到。

当这笔转账的分布式事务走到终态后:

  • 成功,A账户和B账户的金额的变更符合用户预期
  • 失败,A账户和B账户的金额未发生变更,且会告知用户原因

由于TCC旨在将分布式事务通过划分应用业务逻辑来解决,因此在业务模型的设计上也会体现TCC的思想。以账户模型为例,原本账户金额可能只用一个余额字段表达就够了,现在引入了资源预留的概念后,这个余额字段需要拆分为三个:

  1. 账户余额
  2. 处于事务中的入金额 - 可以理解为未达金额
  3. 处于事务中的出金额 - 可以理解为预留金额

后面会对如何操作这几个字段进行说明。

TCC关联概念

很明显,要完成一笔分布式事务,TCC资源只是一环,还需要几个关键角色的通力合作:

  1. 分布式事务发起方
  2. 分布式事务协调者(Transaction Coordinator - 后文中简称为TC)
  3. 分布式事务元数据存储

分布式事务发起方的主要责任是启动分布式事务,同时负责调用参与者的服务,并记录相应的事务日志。

分布式事务协调者的主要责任是保障分布式事务在各种状况下都能够推进到终态。

分布式事务元数据存储则指的是事务信息的保存地点,事务信息包含下面三类:

  1. 主事务记录 - Activity
  2. 分支事务记录 - Action
  3. 事务状态控制记录 - 主要用于异常处理

TCC调用

TCC资源的调用和其定义是无关的。调用方式则取决于TCC资源的部署视图。总体而言,有三种调用方式:

  1. 服务内部调用
  2. 域内服务间调用
  3. 跨域服务间调用

服务内部调用

如果银行A和银行B正好就是同一家银行,那么这一家银行可以选择将这两个TCC资源部署到一个服务中。此时这两个服务的调用方式就类似于JVM内部调用。

域内服务间调用

如果银行A和银行B正好就是同一家银行,那么这一家银行可以选择将这两个TCC资源部署到不同的服务中。此时这两个服务的调用方式就类似服务间的RPC调用。

跨域服务间调用

如果银行A和银行B不是同一家银行,那么这两个服务势必是在不同的服务中,并且它们的部署都不在一个域内。需要通过各个银行对外暴露的网关接口来完成调用。

一个例子:转账场景下的TCC实现

如果只讲理论的话很容易把自己弄晕,还是以经典的转账为例,来看看如何通过TCC来实现该场景下的分布式事务。

业务场景:银行A的某一账户转账100元给银行B的某一账户。A的当前可用余额为200元。

整体流程表达如下:

在这里插入图片描述
先来看看万事顺意的场景。

银行A作为整个分布式事务的发起方,会开启主事务,然后调用银行B的TCC资源一阶段TRY,通知它有一笔未达金额就要来了。
银行B检查目标账户的状态,额度。没有异常的话增加账户的未达金额,通知银行A我已经就绪,就剩二阶段的执行。

银行A得知银行B准备就绪了,开始执行自己的一阶段。自己作为扣款方,需要减少余额并增加未出金额(体现为预留资源)。准备就绪后会通知TC,可以通知各个参与方执行二阶段的Confirm。

二阶段Confirm的操作也很直观了:对于银行A,将事务中的预留金额减去即可;对于银行B,需要将未达金额减去并增加对应的金额到余额。

显然,事情像上面那样顺利显然是不现实的。如果这个过程中有任何异常发生,比如银行B检查目标账户状态异常,会通过抛异常回滚本地事务,返回异常信息告知银行A这笔业务玩不了,银行A收到后直接放弃自己的一阶段执行,这笔分布式事务就此结束。

上面只列出了一种业务异常场景。业务异常场景的分析并不困难,在理解了业务规则的情况下通常都比较直观。根据各个接入分布式事务的业务特点进行分析即可。

在分布式环境下,对于网络异常以及系统异常场景的分析和处理才是老大难。网络交互越复杂,参与者越多那么异常的场景也就越多。

在下篇文章中,会系统性地看看TCC中的异常场景以及相应的应对手段。

微服务架构的分布式事务控制解决方案

09-06
1、课程简介 Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。        在本套课程中,我们将全面的讲解Spring Cloud技术栈, 从环境的部署到技术的应用,再到项目实战,让我们不仅是学习框架技术的使用,而且可以学习到使用Spring Cloud如何解决实际的问题。 Spring Cloud各个组件相互配合,合作支持了一套完整的微服务架构。 - 注册中心负责服务的注册与发现,很好将各服务连接起来 - 断路器负责监控服务之间的调用情况,连续多次失败进行熔断保护。 - API网关负责转发所有对外的请求和服务 - 配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息 - 链路追踪技术可以将所有的请求数据记录下来,方便我们进行后续分析 - 各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况 2、适应人群 有一定的Java基础,并且要有一定的web开发基础。 3、课程亮点        系统的学习Spring Cloud技术栈,由浅入深的讲解微服务技术。涵盖了基础知识,原理剖析,组件使用,源码分析,优劣分析,替换方案等,以案例的形式讲解微服务中的种种问题和解决方案 l  微服务的基础知识 n  软件架构的发展史 n  微服务的核心知识(CAP,RPC等) l  注册中心 n  Eureka搭建配置服务注册 n  Eureka服务端高可用集群 n  Eureka的原理和源码导读 n  Eureka替换方案Consul n  Consul下载安装&服务注册&高可用 l  服务发现与服务调用 n  Ribbon负载均衡基本使用&源码分析 n  Feign的使用与源码分析 n  Hystrix熔断(雪崩效应,Hystrix使用与原理分析) n  Hystrix替换方案Sentinel l  微服务网关 n  Zuul网关使用&原理分析&源码分析 n  Zuul 1.x 版本的不足与替换方案 n  SpringCloud Gateway深入剖析 l  链路追踪 n  链路追踪的基础知识 n  Sleuth的介绍与使用 n  Sleuth与Zipkin的整合开发 l  配置中心 n  SpringClond Config与bus 开发配置中心 n  开源配置中心Apollo 4、主讲内容 章节一: 1.     微服务基础知识 2.     SpringCloud概述 3.     服务注册中心Eureka 4.     Eureka的替换方案Consul 章节二: 1.     Ribbon实现客户端负载均衡 2.     基于Feign的微服务调用 3.     微服务熔断技术Hystrix 4.     Hystrix的替换方案Sentinel 章节三: 1.     微服务网关Zuul的基本使用 2.     Zuul1.x 版本的不足和替换方案 3.     深入SpringCloud Gateway 4.     链路追踪Sleuth与Zipkin 章节四: 1.     SpringCloud Config的使用 2.     SpringCloud Config结合SpringCloud Bus完成动态配置更新 3.     开源配置中心Apollo
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值