出席分布式事务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 的一个扩展

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

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

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

对于大部分的分布式应用而言，只要数据在规定的时间内达到最终一致性即可。

我们可以把符合传统的 ACID 叫做刚性事务，把满足 BASE 理论的最终一致性事务叫做柔性事务。

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

What's Seata

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

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

官网: https://seata.io/

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

核心价值

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

能力边界

业务无侵入	业务侵入
AT	TCC
XA	Saga

TCC模式

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

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

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

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

Saga模式

基础原理

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

使用场景

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

优势

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

缺点

不保证隔离

参会照片

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

会议内部图片

seata贴纸