分布式事务

问题场景 什么是事务? 事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性： 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态。 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。 隔离性（Isolation）：两个事务的执行是互不干扰的，两个事务时间不会互相影响。 持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。 例如应用程序需要更新多条相关数据时就需要进行事务处理。 什么是分布式事务? 当遇到复杂业务调用时，可能会出现跨库多资源调用(一个事务管理器，多个资源)/多服务调用（多个事务管理器，多个资源），期望全部成功或失败回滚，这就是分布式事务，用以保证“操作多个隔离资源的数据一致性”。 分布式事务与 XA 规范 分布式事务是指会涉及到操作多个数据库的事务，同样必须保证 ACID。其就是将对同一库事务的概念扩大到了对多个库的事务：对同一库的 SQL 操作对应了分布式事务中对一个库的事务。 X/Open XA 定义了分布式事务处理的规范，并由数据库厂商在驱动层面进行实现。XA 规范的基础是两阶段提交协议

【这章基本上是照着畅购课件走的，有课件的同学可以直接跳过】 结构说明 结构说明： changgou-gateway 网关模块，根据网站的规模和需要，可以将综合逻辑相关的服务用网关路由组合到一起。在这里还可以做鉴权和限流相关操作。 changgou-service 微服务模块，该模块用于存放所有独立的微服务工程。 changgou-service_api 对应工程的JavaBean、Feign、以及Hystrix配置，该工程主要对外提供依赖。 changgou-transaction-fescar 分布式事务模块，将分布式事务抽取到该工程中，任何工程如需要使用分布式事务，只需依赖该工程即可。 changgou-web web服务工程，对应功能模块如需要调用多个微服务，可以将他们写入到该模块中，例如网站后台、网站前台等 需要工程模块的同学可以直接移步我的GitHub下载 畅购父工程 来源： CSDN 作者： 我没有在划水 链接： https://blog.csdn.net/foxException/article/details/103605317

今天看到WCF，说是整合了Net remoting，Web service。。。下面列一下概念。 一 WCF 概括地说，WCF具有如下的优势： 1、统一性 前面已经叙述，WCF是对于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区别，我们仍然可以像创建面向对象的应用程序那样，利用WCF来创建面向服务的应用程序。 2、互操作性 由于WCF最基本的通信机制是SOAP，这就保证了系统之间的互操作性，即使是运行不同的上下文中。这种通信可以是基于.Net到.Net间的通信。 可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web Service，例如J2EE应用服务器（如WebSphere，WebLogic）。应用程序可以运行在Windows操作系统下，也可以运行在其他的操作系统，如Sun Solaris，HP Unix，Linux等等。 3、安全与可信赖 WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。 在SOAP的header中增加了WS-ReliableMessaging允许可信赖的端对端通信。而建立在WS

一 WCF 概括地说，WCF具有如下的优势： 1、统一性 前面已经叙述，WCF是对于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区别，我们仍然可以像创建面向对象的应用程序那样，利用WCF来创建面向服务的应用程序。 2、互操作性 由于WCF最基本的通信机制是SOAP，这就保证了系统之间的互操作性，即使是运行不同的上下文中。这种通信可以是基于.Net到.Net间的通信。 可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web Service，例如J2EE应用服务器（如WebSphere，WebLogic）。应用程序可以运行在Windows操作系统下，也可以运行在其他的操作系统，如Sun Solaris，HP Unix，Linux等等。 3、安全与可信赖 WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。 在SOAP的header中增加了WS-ReliableMessaging允许可信赖的端对端通信。而建立在WS-Coordination和WS-AtomicTransaction之上的基于SOAP格式交换的信息

一 WCF 概括地说，WCF具有如下的优势： 1、统一性 前面已经叙述，WCF是对于ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区别，我们仍然可以像创建面向对象的应用程序那样，利用WCF来创建面向服务的应用程序。 2、互操作性 由于WCF最基本的通信机制是SOAP，这就保证了系统之间的互操作性，即使是运行不同的上下文中。这种通信可以是基于.Net到.Net间的通信。 可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web Service，例如J2EE应用服务器（如WebSphere，WebLogic）。应用程序可以运行在Windows操作系统下，也可以运行在其他的操作系统，如Sun Solaris，HP Unix，Linux等等。 3、安全与可信赖 WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。 在SOAP的header中增加了WS-ReliableMessaging允许可信赖的端对端通信。而建立在WS-Coordination和WS-AtomicTransaction之上的基于SOAP格式交换的信息

分布式事务中间件Seata的设计原理 那 Seata 是怎么做到的呢？下面说说它的各个模块之间的关系。 Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。 Seata 内部定义了 3个模块来处理全局事务和分支事务的关系和处理过程，这三个组件分别是： Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。 Transaction Manager (TM)： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。 Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。 简要说说整个全局事务的执行步骤： 1.TM 向 TC 申请开启一个全局事务，TC 创建全局事务后返回全局唯一的 XID，XID 会在全局事务的上下文中传播； 2.RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务； 3.TM 向 TC 发起全局提交或回滚； 4.TC 调度 XID 下的分支事务完成提交或者回滚。 与 XA 方案有什么不同？ Seata 的事务提交方式跟 XA

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。 ACID 指数据库事务正确执行的四个基本要素： 原子性（Atomicity） 一致性（Consistency） 隔离性（Isolation） 持久性（Durability） CAP CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性 ：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 可用性 ：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 分区容忍性 ：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 BASE理论 BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是： 我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。 Basically Available（基本可用） Soft state（软状态） Eventually consistent（最终一致性）

一个复杂的系统往往都是从一个小而简的系统发展衍化而来，为了满足日益增长的业务需求，不断的增加系统的复杂度，从单体架构逐步发展为分布式架构，而分布式系统架构的设计主要关注：高性能，高可用，高拓展 分布式事务 高可用是指系统无中断的执行功能的能了，代表了系统的可用程度，是进行系统设计时必须要遵守的准则之一。 而高可用的实现方案，无外乎就是冗余，就存储的高可用而言，问题不在于如何进行数据备份，而在于如何规避数据不一致对业务造成的影响 对于分布式系统而言，要保证分布式系统中的数据一致性就需要一种方案，可以保证数据在子系统中始终保持一致，避免业务出现问题，这种实现方案就叫做分布式事务，要么一起成功，要么一起失败，必须是一个整体性的事务 理论基础 ​ 在讲解具体方案之前，有必要了解一下分布式中数据设计需要遵循的理论基础，CAP理论和BACS理论，为后面的实践铺平道路 CAP理论 CAP：Consistency Acailability Partition tolerance 的简写 Consistency：一致性 对某个客户端来说，读操作能够返回最新的写操作结果 Acailability：可用性 非故障节点在合理的时间内返回合理的响应 Partition tolerance：分区容错性 当出现网络分区后，系统能够继续提供服务 你知道什么是网络分区吗 ~~

闲话 最近简单的学习了一下 springboot，记录下自己的一些学习心得，没有体系，没有深入讲解，基本只涉及到一些概念级，权当随笔记录。。他日翻看时，希望能有所帮助，肯定也有理解不到位之处，还请大家指正 为什么会有 spring 学习一项技术，我们首先需要弄明白，这项技术出现的意义是什么，它能够解决什么场景问题，知其然，必先知其所以然 一般大型的企业级java应用，都会包含很多的内容模块，包括各种接口、逻辑、页面、存储等，它们之间可能存在复杂的依赖关系，如何对他们进行统一的管理和调度是影响开发效率的重要因素 容器化管理我们的应用程序，是上述问题的通用解决方案：应用的开发针对 pojo、bean或者组件，然后交由容器去负责组装调用，实现解耦 在spring之前，java官方推荐的解决方案是 EJB，但是 EJB 是一个非常重型的框架，上手成本很高，对于中小型的企业应用支持并友好 于是民间组织在 EJB 的容器化管理的基础上，创建了 spring，相对来说更轻量级的开发框架，简单对比 EJB 的话，他俩的优缺点： EJB 面向的是组件级容器管理，spring 则是 bean 的管理，更细粒度，对于开发的理解更容易 EJB 和 spring 都支持 ioc 和 aop，但是 spring 封装的功能更强大简单，早期spring只支持xml配置方式，ejb只支持注解方式，随着发展

1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2、分布式事务的产生的原因 2.1、数据库分库分表 当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，以后有空详细说，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。 2.2、应用SOA化 所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。 以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！ 3、事务的ACID特性 3.1、原子性（A） 所谓的原子性就是说