Seata

- 起源 - Saga模型起源于1987年 Hector Garcia-Molina，Kenneth Salem 发表的论文《Sagas》，是分布式事务相关概念最早出现的。 Saga模型是把一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块和补偿模块（对应TCC中的Confirm和Cancel），当Saga事务中任意一个本地事务出错时，可以通过调用相关的补偿方法恢复之前的事务，达到事务最终一致性。 - 组成 - Saga模型主要分： 一串子事务(本地事务)的事务链 每个Saga子事务Tn, 都有对应的补偿定义 Cn用于撤销Tn造成的结果 每个Tn都没有“预留”动作，直接提交到库。 执行顺序： 子事务序列 T1, T2, …, Tn得以完成 (最佳情况) 或者序列 T1, T2, …, Tj, Cj-1, …, C2, C1, 0 < j < n, 得以完成 数据隔离性： 业务层控制并发 在应用层加锁 应用层预先冻结资源等 恢复方式： 向后恢复：补偿所有已完成的事务，如果任一子事务失败 向前恢复：重试失败的事务，假设每个子事务最终都会成功 从Saga模型的上述定义中，Saga 模型可以满足事务的三个特性： 原子性：Saga 协调器协调事务链中的本地事务要么全部提交，要么全部回滚。 一致性：Saga 事务可以实现最终一致性。 持久性：基于本地事务，所以这个特性可以很好实现

1.logs文件夹 在bin同级目录下新建logs文件夹，在logs中新建seata_gc.log 2.内存 修改bat文件的jvm内存配置 来源： oschina 链接： https://my.oschina.net/u/3668429/blog/4952931

来源：http://dwz.date/eaAm 分布式事务是什么 数据库事务的特性包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durabilily），简称 ACID。 在数据库执行中，多个并发执行的事务如果涉及到同一份数据的读写就容易出现数据不一致的情况，不一致的异常现象有以下几种。 脏读 ，是指一个事务中访问到了另外一个事务未提交的数据。例如事务 T1 中修改的数据项在尚未提交的情况下被其他事务（T2）读取到，如果 T1 进行回滚操作，则 T2 刚刚读取到的数据实际并不存在。 不可重复读 ，是指一个事务读取同一条记录 2 次，得到的结果不一致。例如事务 T1 第一次读取数据，接下来 T2 对其中的数据进行了更新或者删除，并且 Commit 成功。这时候 T1 再次读取这些数据，那么会得到 T2 修改后的数据，发现数据已经变更，这样 T1 在一个事务中的两次读取，返回的结果集会不一致。 幻读 ，是指一个事务读取 2 次，得到的记录条数不一致。例如事务 T1 查询获得一个结果集，T2 插入新的数据，T2 Commit 成功后，T1 再次执行同样的查询，此时得到的结果集记录数不同。 脏读、不可重复读和幻读有以下的包含关系，如果发生了脏读，那么幻读和不可重复读都有可能出现。 不同隔离级别 SQL 标准根据三种不一致的异常现象

前期回顾: 1、干货来啦！分布式场景之刚性事务-2PC详解 2、敲黑板：分布式架构，刚性事务-2PC必须注意的问题！+3PC详细解说！ - 刚性事务总结 - 在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等等。但是没有说分布式事务的现象或者场景，我总结了分布式事务的触发场景大约有以下几种： 1、跨数据库分布式事务：数据库的物理分割下保障跨库操作的ACID。 2、跨服务分布式事务：服务的网络分割下保障多服务的事务完整性。 3、混合式分布式事务：跨数据库分布式事务 + 跨服务分布式事务。 最根本的原因就是事务参与者出现在不同的网络中，需要网络通讯进行交互，因此不可避免的出现失败、超时等情况，所以需要分布式事务来处理。 前面也大体说了下事务的解决方案，接下来咱们先来个完整的结论： 业务规避 > BASE 柔性事务 > CP 刚性事务 。刚性事务已经介绍过了，因为追求CP，通常使用在金融等强一致性场景的行业。刚性事务首先有XA规范，这个XA规范的实现方案是2PC，业界开源框架有Atomikos、Bitronix、Seata XA模型及各大数据库厂商对XA的落地。 目前国内对刚性事务使用最广泛的是蚂蚁金服的2PC，但是并不开源。不够我们可以从Seata XA模型去看到一部分蚂蚁2PC的影子

SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFA Stack（ S calable O pen F inancial A rchitecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 " SOFA WEEKLY " 的形式回复 1 、 @ 叶毅威 提问： 请教下 SOFARegistry 数据持久化在哪里啊? A：SOFARegistry 的元数据（注册中心自身的 IP 列表之类的数据）存储在 meta 角色内，使用 JRaft 进行存储。应用的发布数据保存在 data 角色的内存中，采用三副本（可配置）的方式实现高可用。 SO FARegistry ： https://github.com

SOFA WEEKLY | 每周精选，筛选每周精华问答 同步开源进展，欢迎留言互动 SOFA Stack（ S calable O pen F inancial A rchitecture Stack）是蚂蚁集团自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics 监控度量，分布式高可用消息队列，分布式事务框架，分布式数据库代理层等组件，也是在金融场景里锤炼出来的最佳实践。 SOFAStack 官网: https://www.sofastack.tech SOFAStack: https://github.com/sofastack 每周读者问答提炼 欢迎大家向公众号留言提问或在群里与我们互动 我们会筛选重点问题通过 " SOFA WEEKLY " 的形式回复 1 、 吴小彬 提问 请教下，如果分支事务中使用了分库分表中间件（shardingsphere-proxy、mycat 等），Seata-AT 模式是不是不能用的？是只可以用 TCC 模式吗？ 现在的 shardingsphereProxy 中间件（不是 shardingsphereJdbc ）用 AT 模式，它对微服务来说就是一个 MySQL 连接，它是怎么知道微服务调用链中的

🐎 小马哥 & Josh Long 🐲 喜欢写一首诗一般的代码，更喜欢和你共同 code review，英雄的相惜，犹如时间沉淀下来的对话，历久方弥新。 相见如故，@杭州。 4 月 18 日，Josh Long 来到了阿里巴巴西溪园区，我们向其演示了 Spring Cloud Alibaba 各个组件的功能和实现方式，Josh Long 看完意犹未尽，表示会在新的 Spring Tips 视频再次介绍 Spring Cloud Alibaba 中的其他组件。（点击文末阅读原文，访问上一期spring-tips-bootiful-alibaba） 画外音：首次遇见，@北京： 我和 Josh Long 的一天 一天后， Spring Cloud Alibaba 发布了首个 GA 版本，此次开发历时 267 天，汇集 26 位 contributor 的努力，覆盖 Spring Cloud Edgware、 Spring Cloud Finchley 和 Spring Cloud Greenwich 3 个版本。 Spring Cloud 联合创始人 Spencer Gibb 在 Spring 官网的博客页面宣布该发板消息。随后，Spring Cloud 官方 Twitter 也发布了此消息 Spring 贺电史： Spring Cloud Alibaba发布第二个版本，Spring

Spring Cloud Alibaba 1.入门简介 1.1 为什么会出现SpringCloud alibaba spring cloud Netflix进入维护模式 1.2 是什么 2018.10.31, Spring cloud Alibaba正式入驻了Spring Cloud官方孵化器,并在Maven中央库发布了第一个版本. 1.3 能干嘛 服务限流降级 默认支持Servlet、Feign、RestTemplate、Dubbo和RocketMQ限流降级功能的接入,可以在运行时通过控制台实时修改限流降级规则,还支持查看限流降级Metrics监控 服务注册与发现 适配Spring Cloud服务注册与发现标准,默认集成了Ribbon的支持 分布式配置管理 支持分布式系统中的外部化配置,配置更改时自动刷新 消息驱动能力 基于Spring Cloud Stream为微服务应用构建消息驱动能力 阿里云存储对象 阿里云提供的海量、安全、低成本、高可靠的云存储服务.支持在任何应用、任何时间、任何地点存储和访问任意类型的数据 分布式任务调度 提供秒级、精准、高可靠、高可用的定时(基于Cron表达式)任务调度服务.同时提供分布式的任务执行模型,如网格任务.网格任务支持海量子任务均匀分配到所有Worker(schedulerx-client)上执行 1.4 怎么用 Sentinel

作者 | 陈健斌（funkye） github id: a364176773 来源| 阿里巴巴云原生公众号 Seata 是一款开源的分布式事务解决方案，star 高达 18100+，社区活跃度极高，致力于在微服务架构下提供高性能和简单易用的分布式事务服务，本文将剖析 Seata-AT 的实现原理，让用户对 AT 模式有更深入的认识。 Seata 事务模式是什么? 1. Seata 对事务的定义 Seata 定义了全局事务的框架。 全局事务定义为若干分支事务的整体协调： TM 向 TC 请求发起（Begin）、提交（Commit）、回滚（Rollback）全局事务。 TM 把代表全局事务的 XID 绑定到分支事务上。 RM 向 TC 注册，把分支事务关联到 XID 代表的全局事务中。 RM 把分支事务的执行结果上报给 TC。（可选） TC 发送分支提交（Branch Commit）或分支回滚（Branch Rollback）命令给 RM。 Seata 的全局事务处理过程，分为两个阶段： 执行阶段 > ：执行分支事务，并保证执行结果满足是可回滚的（Rollbackable）和持久化的（Durable）。 完成阶段 > ：根据执行阶段结果形成的决议，应用通过 TM 发出的全局提交或回滚的请求给 TC，> TC 命令 RM 驱动 分支事务 进行 Commit 或 Rollback。

KubeCon EU 前几天刚刚结束，6月24日 KubeCon China 又要来了。KubeCon + CloudNativeCon + Open Source Summit China 2019，它的前身为 LinuxCon + CloudOpen + ContainerCon China（LC3），是国内开源技术届最大的盛会之一。本次活动将聚焦 Kubernetes 和 Cloud Native 生态最新进展，对于关注云原生领域的同学来说不容错过。 在这次 KuberCon上，蚂蚁金服核心技术团队将举办一场全天的 Workshop，给大家分享分布式架构 SOFAStack、Service Mesh、Serverless、分布式事务 Seata 的实践案例，跟大家一起轻松上手云原生技术。 Service Mesh + Serverless 快速上手 Service Mesh 将服务间通信能力下沉到基础设施，让应用解耦并轻量化。但 Service Mesh 本身的复杂度依然存在，如何轻松的实践 Service Mesh 技术？在活动现场，我们将带你感受 CloudMesh 通过将 Service Mesh 托管在云上，助力轻松实践 Service Mesh 技术。 作为云原生技术前进方向之一， Serverless 架构 让您进一步提高资源利用率，更专注于业务研发