专栏首页穆书伟出席分布式事务Seata 1.0.0 GA典礼

出席分布式事务Seata 1.0.0 GA典礼

前言

图中那个红衣服的就是本人

什么是分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。

本质上来说,分布式事务就是为了保证不同数据库的数据一致性

分布式事务的基础

数据库的 ACID 满足了数据库本地事务的基础,但是它无法满足分布式事务,这个时候衍生了 CAP 和 BASE 两个经典理论。

CAP理论

  • C (一致性):在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本)
  • A (可用性):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。(对数据更新具备高可用性)
  • P (分区容错性):以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在 C 和 A 之间做出选择。 Eureka 主从同步是 AP 系统 Zookeeper 是 CP 系统

BASE理论

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性) 三个短语的缩写。是对 CAP 中AP 的一个扩展

  1. BA 基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。
  2. S 软状态:允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是 CAP 中的不一致。
  3. E 最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。

BASE 解决了 CAP 中理论没有网络延迟,在 BASE 中用软状态和最终一致,保证了延迟后的一致性。

BASE 和 ACID 是相反的,它完全不同于 ACID 的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。

对于大部分的分布式应用而言,只要数据在规定的时间内达到最终一致性即可。 我们可以把符合传统的 ACID 叫做刚性事务,把满足 BASE 理论的最终一致性事务叫做柔性事务。

具体到分布式事务的实现上,业界主要采用了 XA 协议的强一致规范以及柔性事务的最终一致规范

What's Seata

Seata 是一款开源的分布式事务解决方案,提供高性能和简单易用的分布式事务服务。

Github: https://github.com/seata/seata

官网: https://seata.io/

  1. 支持各微服务框架: 目前已支持Dubbo、Spring Cloud、Sofa-RPC、Motan和gRPC等RPC框架,其他框架持续集成中。
  2. AT自动补偿模式: 提供无侵入自动补偿的事务模式,目前已支持MySQL、Oracle的自动补偿模式,PostgreSQL、H2开发中。
  3. TCC模式: 支持用户使用TCC灵活扩展事务。
  4. Saga模式: 提供长事务和服务编排解决方案。
  5. 高可用: 支持基于数据库存储的集群模式,水平扩展能力强。
  6. 高扩展性: 支持各类配置中心、注册中心、序列化、存储、协议序列化、负载均衡等SPI扩展。

AT自动补偿模式

XA 是 X/Open CAE Specification (Distributed Transaction Processing)模型,它定义的 TM(Transaction Manager)与 RM(Resource Manager)之间进行通信的接口。

Java中 的 javax.transaction.xa.XAResource 定义了 XA 接口,它依赖数据库厂商对 jdbc-driver 的具体实现。

  • mysql-connector-java-5.1.30 的实现可参 com.mysql.jdbc.jdbc2.optional.MysqlXAConnection 类。

在 XA 规范中,数据库充当 RM 角色,应用需要充当 TM 的角色,即生成全局的 txId ,调用 XAResource 接口,把多个本地事务协调为全局统一的分布式事务。

目前 XA 有两种实现:

  • 基于一阶段提交( 1PC ) 的 XA 。
  • 基于二阶段提交( 2PC ) 的 XA 。

AT自动补偿模式就是基于一阶段提交的弱XA

核心价值

  1. 低成本:编程模型 不变,轻依赖 不需要为分布式事务场景做特定设计。
  2. 高性能:一阶段提交,不阻塞;连接释放,保证整个系统的吞吐。
  3. 高可用:极端的异常情况下,可以暂时 跳过异常事务,保证系统可用。

能力边界

业务无侵入

业务侵入

AT

TCC

XA

Saga

TCC模式

TCC 模型是把锁的粒度完全交给业务处理,它需要每个子事务业务都实现Try-Confirm / Cancel 接口。

TCC 模式本质也是 2PC ,只是 TCC 在应用层控制。

  • Try:
    • 尝试执行业务
    • 完成所有业务检查(一致性)
    • 预留必须业务资源(准隔离性)
  • Confirm:
    • 确认执行业务;
    • 真正执行业务,不作任何业务检查
    • 只使用Try阶段预留的业务资源
    • Confirm 操作满足幂等性
  • Cancel:
    • 取消执行业务
    • 释放Try阶段预留的业务资源
    • Cancel操作满足幂等性

这三个阶段,都会按本地事务的方式执行。不同于 XA的prepare ,TCC 无需将 XA 的投票期间的所有资源挂起,因此极大的提高了吞吐量。

Saga模式

基础原理

  1. 核心思想是将长事务拆分为多个本地短事务,由 Saga 事务协调器协调,如果正常结束那就正常完成,如果某个步骤失败,则根据相反顺序一次调用补偿操作
  2. Hector & Kenneth 发表论⽂ Sagas (1987)

使用场景

  • 业务流程长,业务流程多
  • 参与者包含其他公司或遗留系统服务,无法提供TCC模式要求的三个接口
  • 典型业务系统: 如金融网络(与外部机构对接)、互联网微贷、渠道整合、分布式架构下服务集成等业务系统
  • 银行业金融机构使用广泛

优势

  • 一阶段提交本地事务、无锁、高性能。
  • 参与者可异步执行、高吞吐
  • 补偿服务易于实现

缺点

  • 不保证隔离

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 物联网时代-新基建-ThingsBoard调试环境搭建

    2020开年之际,科比不幸离世、疫情当道、经济受到了严重的损失。人们都不幸的感慨: 2020年真是太不真实的一年,可以重新来过就好了!国家和政府出台了拯救经济和...

    sanshengshui
  • Netty4.x整合SpringBoot2.x使用Protobuf3详解

    本篇文章主要介绍的是SpringBoot整合Netty以及使用Protobuf进行数据传输的相关内容。Protobuf会介绍下用法,至于Netty在netty ...

    sanshengshui
  • 软件工程师树莓派获取室内温湿度的坎坷之旅

    前几天公司接受到了一份来自阿里飞天园区,IOT部门的小礼物。由于上司比较忙,无暇去顾及。

    sanshengshui
  • spring事务的传播属性--@Transaction的Propagation属性

    REQUIRED(TransactionDefinition.PROPAGATION_REQUIRED),

    IT云清
  • 分布式事务- 二阶段协议

    在单个数据库实例时候,我们可以在一个数据源的事务(本地事务)内做多步数据库操作,在事务内的多个操作要么全部执行生效,要么全部不生效。在多数据实例节点时候,我们对...

    加多
  • (spring)嵌套事务逻辑分析

    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。

    suveng
  • Spring 事务

    关于理论性的内容,我在之前的一篇文章中介绍过,这里不再过多阐述,这里给出之前文章的链接:Spring 事务管理

    希希里之海
  • 关于事务的隔离级别和处理机制的理解

         前几日有一个猎头公司的面试,其中问道我事务隔离这块的知识点,猛一问真是想不起来啊,顿感羞愧啊,回来专门总结一下这方面的知识来夯实一下之前的知识体系,也...

    用户1217611
  • Spring 事务管理

    JavaEdge
  • 理解MySql事务隔离机制、锁以及各种锁协议

    一直以来对数据库的事务隔离机制的理解总是停留在表面,其内容也是看一遍忘一边。这两天决定从原理上理解它,整理成自己的知识。查阅资料的过程中发现好多零碎的概念如果串...

    小小科

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动