出席分布式事务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模式要求的三个接口

• 典型业务系统: 如金融网络(与外部机构对接)、互联网微贷、渠道整合、分布式架构下服务集成等业务系统

• 银行业金融机构使用普遍

优点

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

缺点

• 不保证隔离

参会照片

会议易拉宝，地点放在杭州青年众创空间

会议内部图片

seata贴纸

原文出处：https://www.cnblogs.com/sanshengshui/p/12094894.html