Seata

SOFA:Channel/ ，有趣实用的分布式架构频道。 本文根据 SOFAChannel#10 直播分享整理，主题：分布式事务 Seata 长事务解决方案 Saga 模式详解。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群：23372465，不错过每场直播。 大家好，我是陈龙，花名: 屹远（ long187@github ），是蚂蚁金服分布式事务核心研发，也是 Seata Committer。今天分享的主题是《分布式事务 Seata 长事务解决方案 Saga 模式详解》，将从金融分布式应用开发的痛点出发，结合 Saga 分布式事务的理论和使用场景，讲解如何使用 Seata Saga 状态机来进行服务编排和分布式事务处理，构建更有弹性的金融应用，同时也会从架构、原理、设计、高可用、最佳实践等方面剖析 Saga 状态机的实现。 Seata： https://github.com/seata/seata 金融分布式应用开发的痛点 分布式系统有一个比较明显的问题就是，一个业务流程需要组合一组服务。这样的事情在微服务下就更为明显了，因为这需要业务上的一致性的保证。也就是说，如果一个步骤失败了，那么要么回滚到以前的服务调用，要么不断重试保证所有的步骤都成功。---《左耳听风-弹力设计之“补偿事务”》 而在金融领域微服务架构下的业务流程往往会更复杂，流程很长

> Simple Extensible Autonomous Transacation Architecture， seata 是简单的、可扩展、自主性高的分布式架构 SEATA Server Configure > 因我们使用正式的1.0.0-GA 版本，网上大多数找到的说明都是0.X版本，有不少变动，比如，在server中取消了db_store.sql的脚本，如找不到相关内容，可以通过源码来查找，比如db脚本源码： mysql db script 下载 seata-server 创建数据库（ seata ）,可自定义，在 file.conf 中要用到。 -- -------------------------------- The script used when storeMode is 'db' -------------------------------- -- the table to store GlobalSession data CREATE TABLE IF NOT EXISTS `global_table` ( `xid` VARCHAR(128) NOT NULL, `transaction_id` BIGINT, `status` TINYINT NOT NULL, `application_id` VARCHAR(32), `transaction

a 来源： oschina 链接： https://my.oschina.net/vqishiyu/blog/3175319

本地事务 事务Transaction由一组SQL组成，具有四个ACID特性。 ACID 1. Atomicity 原子性，构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况 2. Consistency 一致性，数据库经过事务操作后从一种状态转变为另一个状态。可以说原子性是从行为上描述，而一致性是从结果上描述 3. Isolation 隔离性，事务操作的数据对象 相对于 其他事务操作的数据对象相互隔离，互不影响 4. Durability 持久性，事务提交后，其结果就是永久性的，即使发生宕机（非磁盘损坏） 事务实现 对于MySQL数据库（InnoDB存储引擎）而言，隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性通过redo log重做日志和undo log回滚日志来保证的。 1. redo log，当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page脏数据，如果这个时候发生非正常的DB服务重启，那么这些数据还没在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机IO），也就是会发生数据丢失，如果这个时候，能够在有一个文件，当buffer

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 平日里，都是看别人的文章，虽开公众号写了不少，但像样的不多。年末了，年终总结也没来得及写，为了输出点像样的东西，立刻就着手这个系列。<span style="color:orangered;">一个键一个字母的敲，边敲边写，文章还在持续更新中，直至完整。</span>相信通过这个系列的系统练习，能有一个大跨步的提升。 专栏简介（是什么？） 结合SpringCloud、SpringCloudAlibaba、Dubbo等开源套件，基于某商场停车业务需求，进行微服务开发实战，力争通过一个案例的实操，掌握微服务架构中常用的技能点，轻松入门。 为什么要写这个专栏（为什么？） 微服务近两年的火热，也将很多公司的架构慢慢转向微服务，但要直接上手微服务，还需要能过实操演练，不断提升，才能在工作中游刃有余。 网络上相关资源很多，但大多散乱无章，不成体系，不利于系统性掌握，无法一步步的深入其中，更不能深刻掌握各个组件在项目中实际融合情况。 虽然也有一些案例，但缺少相关的文档细节描述，对初学者而言，仅靠阅读代码，难免会一知半解。于是，我就琢磨写一个贴合实际场景的小例子，业务无须很复杂，能将这一套技术体系串连起来，自己可以跟着动手实操，通过一步一步的上手，加深对技术栈的理解。 通过本专栏要达成什么目标（到哪里去？）

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 划重点 2019 年公众号发布的文章共有 1452870 字，相当于 2 本《新华字典》 2019 年这些历程我们一起走过 1月 阿里巴巴李响入选 CNCF 技术监督委员会 9 人名单 阿里云成国内唯一入选 Gartner 公布《公有云容器服务竞争格局》报告企业 2月 阿里云开源 GPU Sharing，首次解决行业 GPU 资源共享调度痛点 3月 阿里云云原生产品家族公布，国内最全 蚂蚁金服加入阿里中间件开源分布式事务项目 Fescar，并贡献了 TCC 模式，Fescar 随即品牌升级为 Seata 4月 阿里云与 CNCF 共同开发的《CNCF x Alibaba 云原生技术公开课》正式上线 分布式任务调度平台 SchedulerX 2.0 公有云全面上线 阿里云链路追踪云产品正式商业化，提供基于 OpenTracing 规范的全链路追踪解决方案 阿里云消息队列 RabbitMQ 版正式商业化发布 5月 KubeCon EU 2019 在巴塞罗那举办，阿里巴巴共有 10 个技术演讲入选 Apache Dubbo 从 Apache 基金会孵化器毕业，成为顶级项目 阿里云 ARMS 云产品上线 Prometheus 监控云服务，国内首次推出云原生及周边生态的可观测性解决方案 阿里巴巴张乎兴成为 Apache

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Seata 的动态降级需要结合配置中心的动态配置订阅功能。动态配置订阅，即通过配置中心监听订阅，根据需要读取已更新的缓存值，ZK、Apollo、Nacos 等第三方配置中心都有现成的监听器可实现动态刷新配置；动态降级，即通过动态更新指定配置参数值，使得 Seata 能够在运行过程中动态控制全局事务失效（目前只有 AT 模式有这个功能）。 那么 Seata 支持的多个配置中心是如何适配不同的动态配置订阅以及如何实现降级的呢？下面从源码的层面详细给大家讲解一番。 动态配置订阅 Seata 配置中心有一个监听器基准接口，它主要有一个抽象方法和 default 方法，如下： io.seata.config.ConfigurationChangeListener 该监听器基准接口主要有两个实现类型： 实现注册配置订阅事件监听器：用于实现各种功能的动态配置订阅，比如 GlobalTransactionalInterceptor 实现了 ConfigurationChangeListener，根据动态配置订阅实现的动态降级功能； 实现配置中心动态订阅功能与适配：对于目前还没有动态订阅功能的 file 类型默认配置中心，可以实现该基准接口来实现动态配置订阅功能；对于阻塞订阅需要另起一个线程去执行

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Seata 可以支持多个第三方配置中心，那么 Seata 是如何同时兼容那么多个配置中心的呢？下面我给大家详细介绍下 Seata 配置中心的实现原理。 配置中心属性加载 在 Seata 配置中心，有两个默认的配置文件： file.conf 是默认的配置属性，registry.conf 主要存储第三方注册中心与配置中心的信息，主要有两大块： registry { # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa # ... } config { # file、nacos 、apollo、zk、consul、etcd3 type = "file" nacos { serverAddr = "localhost" namespace = "" } file { name = "file.conf" } # ... } 其中 registry 为注册中心的配置属性，这里先不讲，config 为配置中心的属性值，默认为 file 类型，即会加载本地的 file.conf 里面的属性，如果 type 为其它类型，那么会从第三方配置中心加载配置属性值。 在 config 模块的 core 目录中，有个配置工厂类 ConfigurationFactory，它的结构如下：

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> GTS 今年双 11 的成绩 今年 2684 亿的背后，有一个默默支撑，低调到几乎被遗忘的中间件云产品——GTS（全局事务服务，Global Transaction Service），稳稳地通过了自 2014 年诞生以来的第 5 次“大考”。 2019 年 11 月 1 日至 12 日，GTS 日均处理分布式事务数量达 亿级 ，每天峰值 TPS 达 万级 。 这背后最重要意义在于：成绩是在给业务应用的设计和开发带来 0 负担 的前提下得到的。 GTS 带来的价值 随着企业的发展，企业业务架构面临数据、服务的分布化，几乎无可避免地要遇到分布式架构带来的数据一致性问题。 GTS 开创性地把分布式事务问题从业务中剥离出来，作为一个独立的技术切面来单独管理，以服务的形式给构建在云上的应用提供简单、易用、高效的分布式事务解决方案。 GTS 给业务应用带来的价值体现在以下几个方面： 架构复杂度降低：分布式事务这个 切面 的技术问题，全部 收敛 到 GTS 提供的服务来解决。 设计和开发成本减轻：业务逻辑的设计和开发，完全不需要针对是否涉及分布式事务而做任何额外的事情，对业务 0 侵入 。 项目交付、迭代速度加快：归因于上述两点，项目得以很快交付和迭代。GTS 赋予业务应用 快速试错 的能力，在这个商业机会瞬息万变的时代

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1.关于Seata 再前不久，我写了一篇关于分布式事务中间件Fescar的解析，没过几天Fescar团队对其进行了品牌升级，取名为Seata(Simpe Extensible Autonomous Transcaction Architecture)，而以前的Fescar的英文全称为Fast & EaSy Commit And Rollback。可以看见Fescar从名字上来看更加局限于Commit和Rollback，而新的品牌名字Seata旨在打造一套一站式分布式事务解决方案。更换名字之后，我对其未来的发展更有信心。 这里先大概回忆一下Seata的整个过程模型: TM:事务的发起者。用来告诉TC，全局事务的开始，提交，回滚。 RM:具体的事务资源，每一个RM都会作为一个分支事务注册在TC。 TC:事务的协调者。也可以看做是Fescar-servr，用于接收我们的事务的注册，提交和回滚。 在之前的文章中对整个角色有个大体的介绍，在这篇文章中我将重点介绍其中的核心角色TC，也就是事务协调器。 2.Transcation Coordinator 为什么之前一直强调TC是核心呢？那因为TC这个角色就好像上帝一样，管控着云云众生的RM和TM。如果TC一旦不好使，那么RM和TM一旦出现小问题，那必定会乱的一塌糊涂