分布式事务

分布式事务解决方案： 一. 基于XA协议的两阶段提交； 二.消息事务+最终一致性 所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败。 开源的RocketMQ就支持这一特性.该方案采用最终一致的，牺牲了一致性，换来了性能的大幅度提升。存在造成数据不一致的风险。 来源： https://www.cnblogs.com/ZJOE80/p/12181728.html

在微服务如火如荼的情况下，越来越多的项目开始尝试改造成微服务架构，微服务即带来了项目开发的方便性，又提高了运维难度以及网络不可靠的概率. 在说微服务的优缺点时，有对比才会更加明显，首先说一下单体式结构 单体式架构 在单体式架构中，系统通常采用分层架构模式（MVC），持久化层、表示层，业务逻辑层。架构主要存在以下问题： 系统内部互相访问，耦合紧密导致难以维护； 各业务领域需要采用相同的技术栈，难以快速应用新技术（例如使用SSH很难向SSM改造）； 对系统的任何修改都必须整个系统一起重新部署/升级； 在系统负载增加时，难以进行水平扩展； 当系统中一处出现问题，会影响整个系统； 为了克服以上缺点，微服务架构应运而生。微服务，又叫微服务架构。微服务就是一些协同工作的小而自治的服务. 微服务架构 优点: 1. 技术异构性 在不同的服务中，可以使用不同的技术来各自开发，只要保证服务间能相互协作即可 2. 弹性 当微服务中的某一个服务不可用时，不会影响整个系统，只会影响相关功能不可用 3. 扩展 易于扩展，使用小的多个服务，更加易于扩展新的功能 4. 简化部署 某个服务的更新部署，不需要重新部署整个应用 5. 可组合 通过组合多个服务，可以提供一些新的功能 6. 可替代 因为每个微服务都比较小，重新实现某一个服务或者直接删除该服务都是可操作的 缺点: 1. 复杂度高 微服务间通过REST

引言 其实事务在数据层、服务层、业务逻辑层多处地方都会使用到，在本篇文章将会为大家一一细说。 其中前面四节是事务的基础，后面的三节是事务的重点，对事务有基础的朋友可以跳过前面四节。 文章有错漏的地方欢迎各位点评。 目录 一、事务的定义 二、事务管理器 三、在ADO.NET中实现事务 四、隐式事务 TransactionScope 五、在WCF中实现事务 六、嵌套式事务 七、异步事务 一、事务的定义 所谓事务,它是一个操作集合，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。典型的例子就像从网上银行系统的帐户A转帐到帐户B，它经过两个阶段：1.从帐户A取出款项。2.把款项放入帐户B中。这两个过程要么同时成功，要么同时失败,这一系列的操作就被称为事务性(Transactional)操作。 在一个事务性操作的环境下，操作有着以下的4种特性，被称为ACID特性 原子性（Atomicity） 当事务结束，它对所有资源状态的改变都被视为一个操作，这些操作要不同时成功，要不同时失败　　 一致性（Consistency） 操作完成后，所有数据必须符合业务规则，否则事务必须中止 隔离性（Isolation） 事务以相互隔离的方式执行，事务以外的实体无法知道事务过程中的中间状态 持久性（Durable） 事务提交后，数据必须以一种持久性方式存储起来 回到目录 二、事务管理器

1 分布式事务背景 随着分布式数据库技术的发展越来越成熟，业内对于分布式数据库的要求也由曾经只用满足解决海量数据的存储和读取这类边缘业务向核心交易业务转变。分布式数据库如果要满足核心账务类交易需求，则其需要完善分布式事务，向传统关系型数据库看齐。即分布式事务的实现也需要像传统关系型数据库的事务一样满足事务的标准要求及定义，即ACID特征。 分布式数据库的数据是进行多机器多节点分散存储的，这样的存储架构为实现分布式事务带来了极大的难度。数据事务操作时，事务操作会结合数据分布情况，到不同的存储位置上去执行，而这个存储位置位于网络中的不同机器的不同磁盘上。 2 事务基本概念 2.1 事务使用场景 银行应用是一个经典案例，可以解释事务应用的必要性。假设银行数据库有两张表，支票账户表（check）和存款账户表（save）。现在要从LiLei的支票账户里转账200元到她的存款账户，那么需要至少完成3步操作： 检查支票存款账户的余额是否大于200元； 从支票存款账户余额中减去200元； 在存款账户余额中增加200元； 所有的操作被打包在一个事务里执行，如果某一步失败，就回滚所有已完成步骤。事务操作一般用 START TRANSACTION 语句开始一个事务，用 COMMIT 语句提交整个事务，永久地修改数据，或者用 ROLLBACK 语句回滚整个事务，取消已做的修改。事务SQL操作样例如下：

http://luohonghong.blog.163.com/blog/static/78312058201142411533316/ SQLServer查看和解决死锁的方法 2011-05-24 11:05:33 | 分类： SQL | 字号 订阅 在master数据库中新建以下存储过程 --处理死锁 -- 查看当前进程,或死锁进程,并能自动杀掉死进程 -- 因为是针对死的,所以如果有死锁进程,只能查看死锁进程 -- 当然,你可以通过参数控制,不管有没有死锁,都只查看死锁进程 --调用示例 exec p_lockinfo create proc [dbo].[p_lockinfo] @kill_lock_spid bit=1, --是否杀掉死锁的进程,1 杀掉, 0 仅显示 @show_spid_if_nolock bit=1 --如果没有死锁的进程,是否显示正常进程信息,1 显示,0 不显示 as declare @count int,@s nvarchar(1000),@i int select id=identity(int,1,1),标志, 进程ID=spid,线程ID=kpid,块进程ID=blocked,数据库ID=dbid, 数据库名=db_name(dbid),用户ID=uid,用户名=loginame,累计CPU时间=cpu, 登陆时间=login_time

1. 死锁原理 根据操作系统中的定义：死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。 死锁的四个必要条件： 互斥条件 (Mutual exclusion) ：资源不能被共享，只能由一个进程使用。 请求与保持条件 (Hold and wait) ：已经得到资源的进程可以再次申请新的资源。 非剥夺条件 (No pre-emption) ：已经分配的资源不能从相应的进程中被强制地剥夺。 循环等待条件 (Circular wait) ：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。 对应到 SQL Server 中，当在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁；这些资源可能是 ：单行 (RID ，堆中的单行 ) 、索引中的键 (KEY ，行锁 ) 、页 (PAG ， 8KB) 、区结构 (EXT ，连续的 8 页 ) 、堆或 B 树 (HOBT) 、表 (TAB ，包括数据和索引 ) 、文件 (File ，数据库文件 ) 、应用程序专用资源 (APP) 、元数据 (METADATA) 、分配单元 (Allocation_Unit) 、整个数据库 (DB) 。 一个死锁示例如下图所示： 说明： T1 、 T2 表示两个任务； R1 和

前言 fescar发布已有时日，分布式事务一直是业界备受关注的领域，fescar发布一个月左右便受到了近5000个star足以说明其热度。当然，在fescar出来之前，已经有比较成熟的分布式事务的解决方案开源了，比较典型的方案如LCN（https://github.com/codingapi/tx-lcn）的2pc型无侵入事务，目前lcn已发展到5.0，已支持和fescar事务模型类似的TCX型事务。还有如TCC型事务实现hmily（https://github.com/yu199195/hmily）、tcc-transaction(https://github.com/changmingxie/tcc-transaction)等。在微服务架构流行的当下、阿里这种开源大户背景下，fescar的发布无疑又掀起了研究分布式事务的热潮。fescar脱胎于阿里云商业分布式事务服务GTS，在线上环境提供这种公共服务其模式肯定经受了非常严苛的考验。其分布式事务模型TXC又仿于传统事务模型XA方案，主要区别在于资源管理器的定位一个在应用层一个在数据库层。博主觉得fescar的txc模型实现非常有研究的价值，所以今天我们来好好翻一翻fescar项目的代码。本文篇幅较长，浏览并理解本文大概耗时30~60分钟左右。 项目地址 fescar：https://github.com/alibaba

第1章 微服务入门 本章中将概要介绍微服务与传统应用之间的差异与实现优势，以便于帮助同学们更加清晰微服务在项目开发中的定位。 1-1 课程导学 试看 1-2 ***学前必读***（助你平稳踩坑，畅学无忧，课程学习与解决问题指南） 1-3 传统应用带来的问题 1-4 微服务概述 第2章 演示环境构建 本章中将通过一系列的基本演示，让同学们可以对Dubbo有一个快速直观的认识。当前项目中构建了目前Dubbo的两种主流兼容框架Spring和Springboot，并且都进行了Dubbo集成，以便于适应多种需求下的应对使用。 2-1 基础环境构建介绍 2-2 Spring基础环境构建 2-3 Spring的直连提供者 2-4 SpringBoot基础环境构建 2-5 SpringBoot直连提供者演示 2-6 注册中心概述 2-7 Zookeeper-windows安装 2-8 Spring集成注册中心 2-9 Springboot集成注册中心 2-10 基于Apache Dubbo结合Springboot构建开发环境 2-11 常见问题集锦 2-12 阶段任务 第3章 业务基础环境构建 经过上一章节的演示，让大家了解到Dubbo与Spring、Springboot集成和基本使用，本章中会将Dubbo与Guns进行集成，构建一个业务系统的基本环境，同时针对API网关进行了一个简单的描述和引入

前言 在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在系统中了。尤其数据量大了后，就需要对数据库进行拆分。 如：注册的用户数据，量大了后，就需要考虑分库分表 一旦数据库进行了分拆，那就出现很多头疼的问题，其中之一就是事务问题。那我们就来看看问题是怎么出现的？ 场景 先来上个图 进行数据拆分后，就类似上面的架构。 上图中我们就拿用户的数据进行举例，用户量一旦几千万时，就需要进行分库分表；上图就分了3个库，每个库都保证了高可用。 这样的架构设计，会遇到事务问题，我们来看看具体的业务场景：用户A转账100元给用户B，这个业务比较简单，我们来分析一下里面具体的步骤： 1、用户A的账户先扣除100元 2、再把用户B的账户加100元 逻辑很简单，上伪代码 代码也是比较清晰的，感觉没有什么问题，那我们来分析一下问题在哪？ 问题 我们看到在转账业务中，有两步，一个是操作用户A扣钱，一个是操作用户B加钱 如果在同一个数据库中进行，可以保证这两步操作，要么同时成功，要么同时不成功。这样就保证了转账的数据一致性。 但是如果用户A的数据在集群A中，用户B在集群B中呢？因为他们不在同一个事务中；如用户A扣款成功，但用户B加钱失败了；那就坑了，数据不完整了。 类似这种问题在微服务架构会更多，因为各个服务都是独立的模块，都是远程调用，都没法在同一个事务中，都会遇到事务问题。 那怎么解决

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