Seata

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 一、背景 传统单体系统时代，一个系统操作一个数据库存储。在系统运行时，单次请求或者说单个线程内对同一数据库数据的多次操作，均可通过开启本地事务，依赖数据库提供的事务特性，实现单个请求涉及数据操作的事务管理。但随着系统业务快速增长，单机系统无法支撑增长后的业务体量，数据库拆分、根据存储特性选用多种数据存储、系统拆分为微服务架构等都是常见的解决手段。 但是伴随这架构演进，在微服务架构体系中，传统单体系统中依赖本地事务的方式在分布式环境中已经无法满足需求，因为一个请求涉及的数据操作可能涉及多个服务、多次远程调用甚至多个数据存储。因此，在微服务架构体系，倘若特定场景下的核心业务流程，需要在业务处理时实现单次请求的事务管理，必须引入满足架构要求、满足业务要求的分布式事务技术。 本文主要是结合笔者自身在项目中特定业务落地分布式事务管理时对各项分布式事务解决方案的一些调研和思考，由于三阶段提交并未发现有成熟的开源技术，所以本文并未涉及。另外个人建议先对分布式相关理论比如：CAP、BASE等有基本了解后，再来深入思考各种解决方案，就不会有看时懂了完事忘了的感觉。 二、常见的解决方案 一般产生分布式事务的技术场景有下面三个方面： 微服务下跨服务操作不通数据库实例 单体系统跨数据库实例

关于事务的几点常识 本地事务 该类事务需要满足四大特性： ACID （原子性、一致性、隔离性、持久性），仅限于对单一数据库资源的访问控制。 原子性（ Atomicity ）：指事务作为整体来执行，要么全部执行，要么全部不执行。 一致性（ Consistency ）：指事务应确保数据从一个一致的状态转变为另一个一致状态。 隔离性（ Isolation ）：指多个事务并发时，一个事务的执行不应影响其它事务的执行。 持久性（ Durability ）：指已提交的事务修改数据会被持久保存。 柔性事务 如果将实现了 ACID 的四大事务特性的事务成为刚性事务的话，那么基于 BASE 事务要素的事务则成为柔性事务。 BASE 是基本可用、柔性状态和最终一致性这三个特性的缩写。 基本可用（ Basically Available ）：允许分布式事务参与方不一定要同时在线。 柔性状态（ Soft state ）：则允许系统状态更新有一定的延时。 最终一致性（ Eventually consistent ）：通常是通过消息传递的方式保证系统的 最终一致性 。 在 ACID 事务中对隔离性的要求很高，在事务执行过程中，必须将所有的资源锁定。而柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面移至业务层面。通过放宽对 强一致性 的要求，来换取系统吞吐量的提升。 基于 XA 规范的两阶段提交

什么是分布式事务问题？ 单体应用 　　单体应用中，一个业务操作需要调用三个模块完成，此时数据的一致性由本地事务来保证。 微服务应用 　　随着业务需求的变化，单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用，分别使用独立的数据源，业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证。 小结 　　在微服务架构中由于全局数据一致性没法保证产生的问题就是分布式事务问题。简单来说，一次业务操作需要操作多个数据源或需要进行远程调用，就会产生分布式事务问题。 Seata 是什么? 　　Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。 　　官网： http://seata.io/ Seata 组成 Transaction ID(XID) 　　全局唯一的事务id 三组件 　　Transaction Coordinator(TC)：事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚 　　Transaction Manager(TM)：控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议 　　Resource Manager(RM)

基于SpringCloud分布式架构 为什么要使用分布式架构 Spring Cloud 专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖 分布式/版本化配置 服务注册和发现 路由 Service-to-Service 调用 负载均衡 断路器 分布式消息传递 这是分布式的优点，这样看起来可能比较抽象，举个例子来说，对于单体服务来说，如果我想更新订单中的某个功能，我是不是需要重启整个服务。 这个时候就会导致整个项目都处于不可用状态，或者在处理订单的时候由于程序代码写的有问题，导致死锁了，这个时候也会导致整个服务处于宕机专改，容错率很差。 但是分布式不同，如上图所示，订单服务、售后服务、用户服务都是独立的服务，如果需要更新订单服务或者订单服务发生死锁，受影响的只会是订单服务，售后服务与用户服务还是可以正常工作的，这就是分布式相对单体来说最大的优势之一。 分布式基础组件 Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。 Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。 Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务

背景 Spring 框架提供了许多接口，可以使用这些接口来定制化 bean ，而非简单的 getter/setter 或者构造器注入。细翻 Spring Cloud Netflix、Spring Cloud Alibaba 等这些构建在 Spring Framework 的成熟框架源码，你会发现大量的扩展 bean 例如 Eureka 健康检查 package org.springframework.cloud.netflix.eureka; public class EurekaHealthCheckHandler implements InitializingBean {} Seata Feign 配置 package com.alibaba.cloud.seata.feign; public class SeataContextBeanPostProcessor implements BeanPostProcessor {} 代码示例 DemoBean @Slf4j public class DemoBean implements InitializingBean { public DemoBean() { log.info( "--> instantiate " ); } @PostConstruct public void postConstruct() { log

　　 转自： 如何选择分布式事务解决方案？ 导读 　　分布式事务中涉及的参与者分布在异步网络中，参与者通过网络通信来达到分布式一致性，网络通信不可避免出现失败、超时的情况，因此分布式事务的实现比本地事务面临更多的困难。本文归纳总结五种分布式事务解决方案，并剖析其特点。较长，同学们可收藏后再看。 概述 　　事务是一组不可分组的操作集合，这些操作要么都成功执行，要么都取消执行。最典型的需要事务的场景是银行账户间的转账：假如 A 账户要给 B 账户转账 100 元，那么 A 账户要扣减 100 元，B 账户要增加 100 元，这两个账户的数据变更都成功才可算作转账成功。更严格来说，可以用 ACID 四个特性表述事务： Atomicity：原子性，事务中的所有操作要么都成功执行，要么都取消执行，不能存在部分执行，部分不执行的状态。 Consistency：一致性，举个例子简单的理解就是，A、B 两个账户各有 100 元，无论两个账户并发相互转账多少次，两个账户的资金总额依然是 200 元。 Isolation：隔离性，并发事务之间的相互影响程度，隔离性也是分级别的：读未提交、读已提交、可重复读等。 Durability：持久性，事务完成后对数据的更改不会丢失。 　　单体数据库不涉及网络交互，所以在多表之间实现事务是比较简单的，这种事务我们称之为本地事务。 　

作者 | 于雨、何鑫铭 等 引语 计算机技术浪潮每 10 年都有一次技术颠覆，相关知识体系最迟每 5 年都会革新一次，大概每两年贬值一半，在应用服务通信框架领域亦然。凡是有长期生命的通信框架，大概有 5 年的成长期和 5 年的稳定成熟期。每个时代都有其匹配的应用通信框架，在 20 年前的 2G 时代，强跨语言跨平台而弱性能的 gRPC 是不会被采用的。 每个通信框架，不同的人从不同角度看出不同的结论：初学者看重易用易学，性能测评者注重性能，应用架构师考虑其维护成本，老板则考虑则综合成本。一个应用通信框架的性能固然重要，其稳定性和进化能力更重要，得到有效维护的框架可在长时间单位内降低其综合成本：学习成本、维护成本、升级成本和更换成本。 **什么是 Dubbo-go？**第一，它是 Dubbo 的 Go 语言版本，全面兼容 Dubbo 是其第一要义；第二，它是一个 Go 语言应用通信框架，会充分利用作为云原生时代第一语言---Go 语言的优势，扩展 dubbo 的能力。 2008 年诞生的 Dubbo 已有十多年历史，依靠阿里和其社区，历久弥新。2016 年发布的 Dubbo-go 也已进入第五个年头，如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5 终于发布了。 回首过往，Dubbo-go 已经具备如下能力： 互联互通：打通了 gRPC 和 Spring

概述 本示例模拟服务器设备运维授权功能，使用 seata 来实现分布式事务一致性。 Seata官方文档地址： http://seata.io/zh-cn/docs/overview/what-is-seata.html Spring cloud参考文档： https://spring.io/projects/spring-cloud#learn 本示例源码仓库地址： https://github.com/bugbycode/spring_cloud_dev.git 工作准备 开发工具： Eclipse/Myeclipse/ IntelliJ IDEA 任选其一 · 运行环境： jdk1.8 及以上版本 · 数据库： MySQL 5.7 · 示例采用 框架： Spring boot 2.2.4 、 Spring cloud Hoxton.SR5 、 Spring security oauth2 、 Mybatis 、 Element ui 、 Seata 1.3.0 Seata服务部署 1 、下载最 1.3.0版本的Seata 服务， Seata 服务下载地址如下： https://github.com/seata/seata/releases 2 、解压后分别修改 seata 服务配置文件 registry.conf 和 file.conf ，修改后内容分别如下所示：

目录 前言 项目版本 项目说明 Seata服务端部署 Seata客户端集成 cloud-web module-order module-cart module-goods module-wallet 表结构说明 参考资料 系列文章 前言 单体应用被拆分成各个独立的业务模块后，就不得不要去面对分布式事务，好在阿里已经开源分布式事务组件Seata，虽还在迭代中，难免会有bug产生，但随着社区发展及反馈，相信终究会越来越稳定，话不多说让我们开始吧。 项目版本 spring-boot.version： 2.2.5.RELEASE spring-cloud.version： Hoxton.SR3 seata.version： 1.2.0 项目说明 项目模块说明如下： 前端请求接口经由网关服务进行路由转发后进入cloud-web模块，经cloud-web模块调用相应业务微服务模块，执行业务逻辑后响应前端请求。 Seata服务端部署 1.下载Seata服务端部署文件 https://github.com/seata/seata/releases/download/v1.2.0/seata-server-1.2.0.zip 如嫌下载慢，可关注本文下方微信公众号二维码，关注后回复“ 666 ”即可获取开发常用工具包 2.解压至本地目录后，执行seata-server.bat脚本

上篇文章讲解了传统数据库的一些设计注意点。 本篇为第二篇，在大数据量的情况下，如何去提前设计这个表结构，来达到一个比较好的效果。对于团队，对于后续的维护和扩展都带来更大的便利。 自增id 自增id还是可以有，但是不是必须的了。但是建议还是每张表中有一个自增id。 为什么，还是那句话，做数据查询，迁移，排序的时候，有着天然的一些优势。 唯一标识 这个标识无论是token，还是其他例如订单的订单号或者其他唯一标识都行。 重点是唯一，不只是在单系统中唯一，而是需要在并发的情况，也能够保持唯一。 关于分布式id的生成方案，网上已经有很多了，这里就不重复了。谷歌搜索搜索，自己看下原理，跑跑demo，能够满足自己业务的最大并发情况下的唯一即可。 比如说你未来几年的最大并发也就是100，搞个能支持在几千并发下不会出现标识重复的实现方案即可，并发几万，几十万，真的需要吗？ 后续如果真的能够达到几万并发，那说明什么？说明业务火爆了啊。难道还抽不出时间，抽不出人来做一个id生成方案的改造？这里有比较重要的一点，不要太过超前设计，没必要，也没那个时间。 创建时间&修改时间 创建时间和修改时间还是要有的，而且建议时间精确到毫秒级别，在上一篇，我没有说精确多少，那是因为并发不高，秒级完全够了。但是在大数据量的情况下，可能一秒有几十、几百、上千、上万的数据新增都是有可能的。那么秒级在这种情况下完全就不够看了